1972 – Dennis Ritchie invents a powerful gun that shoots both forward and backward simultaneously. Not satisfied with the number of deaths and permanent maimings from that invention he invents C and Unix.

Езь код

std::map<int, bool> myMap;

// Map is filled in with some data here

void SetValue(int key, bool newValue)
{
myMap[key] = newValue;
}

Небольшие ограничения: мап заполняется значениями только один раз, при запуске программы, гарантированно однопоточно. После инициализации SetValue может вызываться из разных потоков для разных ключей (то есть гонок по одному ключу быть не может). Кроме того, вызов SetValue с ключом, которого в мапе нет, исключен (т.е. невозможен).

С моей точки зрения, с данными допущениями код SetValue можно считать потокобезопасным (присвоение bool считаем атомарной операцией, не углубляясь особенно в детали). Конечно, во всех этих допущениях просвечивает некоторое джидайство (к примеру, operator[] у мапа вообще-то для вставки используется), но если их принять, то никакого криминала в подобном грубом обращении с этим STL контейнером не будет.

Моя аргументация тут такова – SetValue() модифицирует только значения, не изменяя состояние контейнера, поэтому для обеспечения потокобезопасности кода в данном конкретном случае необходимо и достаточно обеспечить потокобезопасность оператора присвоения для типа значения. Контр-аргумент коллеги тоже имеет под собой все основания, ведь нигде прямо не написано, что присвоение элементу мапа нового значения – операция потокобезопасное. Я парировал тем, что в MSDN четко описаны случаи инвалидации итераторов, в число которых изменение уже хранимого значения без вставки или удаления нового ключа никаким боком не входит.

Впрочем, мы джедаи опытные и на личности не переходим. Но в итоге трехчасовой беседы с отсылкой к исходникам STL в коде SetValue появился таки появился лок с моим каментом “Меня заставили”.

Я не отрицаю, что в общем случае так делать не надо. Бо и правда, первый же залетевший дятел завтра заменит мап на какую другую неведому зверюшку и все развалится при первом же неосторожном чихе. Или какой юный падаван проигнорирует жЫрные ворнинги в каментах (а ворнинги там знатные – я, в отличие от, код без комментариев не пишу) выкорчует код и без изменений применит там, где не надо, в результате чего и огребет как тумаков от обладателей синего меча, так и поджопников – от владельцев красного, плюс еще щелбанов от юзверей на закуску.

Но в том-то и дело, что в данном конкретном случае речь шла не об абстрактном алгоритме в вакууме, а о весьма конкретном случае, когда мы уже под микроскопом рассматривали логи профайлера в надежде выжать из системы еще кусочек перформанса.

Вопрос  – я и правда провафлил какое-нибудь условие или мне стоило стоять на своем до конца?

Это, доложу вам, полный пиздец.  Кажется, удельная масса кретинов в гугле, как и в большинстве крупных компаний, перевалила критическую.

Ну и как дальше жыдь, я вас спрашиваю?

Вот искренне не понимаю, чем может думать человек, который в новоиспеченный класс вводит зависимость от другого очень толстого объекта при том, что новому классу требуется лишь знать значение одного поля этого объекта. При том, что это поле в рантайме измениться не может.

class MyCoolClass
{
private:
BigFatObject* m_pOtherObject;
public:
MyCoolClass(BigFatObject* _pPtr):
m_pOtherObject(_pPtr)
{
}

void DoSmth()
{
std::string sName = m_pOtherObject->GetName();
// do smth
}

void DoMoreThings()
{
std::string sName = m_pOtherObject->GetName();
// do smth
}

// and other methods. All like this.

}

Вот такого вот горбатого лепят сплошь и рядом. И даже искры сомнения о том, что тут что-то не так, не проскакивает. Зато другим людям, которым посчастливится изменять BigFatObject или которые захотят переиспользовать код класса в другом месте, придется метать гром и молнии.

Вот объясните мне, они действительно просто не понимают, что тут нужно было передать в конструктор строку, вместо того, чтобы пихать указатель, вводя совершенно ненужные зависимости, делая при этом юнит-тестирование пыткой и превращая будущий рефакторинг в ходьбу по минному полю, заодно добавляя вопрос в времени жизни объектов?  Или же это банальное вредительство?

I appreciate you going into the trouble actually visiting this page.  This post represents this blog owner’s point of view on so-called “Online C++ tests” that are used by recruitment agents to select candidates and explains why its author does not take any of these tests anymore. The sole purpose of the post is to be referred to when he is asked to sit one of these to save him the time explaining his position on this issue over and over again. By writing this post, the author did not intend to insult anyone nor pay revenge of any kind to anyone.

Almost every good software developer can find themselves discussing a new exciting career™ opportunity with the potential employer or their agent. Nine from ten, the candidate will be asked to sit a test. A very easy one, should not be too much trouble, person of such experience will not have any problems completing it in no time, they are told. And this is what is terribly wrong about it. You will have problems. No matter how good you are.

I agree that some initial screening may be required. For example, company needs a junior software developer and they need to be sure that candidates understand basic concepts of certain programming language. In this case test will help. It simply must be well prepared, 100% accurate, 100% correct, 100% meaningful and also short, if not too much trouble. The problem is that most of the tests out there don’t have any of this characteristics. The bigger problem is that they are usually put together by those who have never worked in the software development. And the killer problem is that these tests are filled with inconsistencies, discrepancies or simply full of errors (I wanted to use more colorful language here, but this post is going to be a part of my CV, so I better don’t).

About a year ago I was asked to sit an online C++ test.  I had no objections then. I also was interested in the position. The first question was quite obvious. The second had 4 answers and three of them were correct, but according to the question, only one of them was supposed to be correct. I lost all the interest momentarily. I wanted to stop it right then, but I decided to continue. I don’t regret. At least, now I have the proof how bad these tests are . That’s what question number 4 was:

Anyone who knows C++ will see immediately that everything here is totally screwed. At first, Box::returnpointer() returns reference. But the question is “how to return the address”, which means pointer. I don’t know how this rubbish got into the test and I don’t really care, the fact is that the person who really knows C++ will never ever mistake reference for pointer and vice versa. The question makes no sense nor any of the answers is correct.

The next question brought me a joy of guessing what did they really had in mind. The question that came after that, was a masterpiece. Obviously, somebody simply copied and paste the code directly into HTML, so all template definitions simply disappeared.

It’s so screwed I don’t even want to explain anything. Of course, this is a technical error, but what I was supposed to do? Made a guess? Click randomly? Thank you very much, If I wanted to gamble, I’d go and play pokies.

In fact, I did a nice thing. I took those pictures, randomly clicked through the rest of questions (what was the point answering if the test was already compromised?), expectantly failing it. Then I went into the trouble of putting a big email together with those “screen shots” and detailed explanations what was wrong with the test. Surprisingly enough, I was invited to an interview, but at the end of the day it did not work out, but it is an entirely different story.

You may disagree with me – there are a lot of tests that are checked thoroughly. And you will be correct, well known Brainbench tests don’t usually have stuff-ups like above in them. But they are still stuffed, just in different way. They are still made by people who obviously don’t quite understand what software engineer job is about, and half of questions have no relations to how programming language is used in the real life. The second half of Brainbench questions are “find what’s wrong with this piece of shit code”. As a developer, I have to deal with not-so-great code on a regular basis, but what you’ll see in BB tests is beyond any reasonable limits. When commercial software is considered, such code just does not get checked in into the repository. The code review simply stops at the sight of it and the author gets a chance to get rid of it. To top it off, BB has a bad habit of giving code snippets in images. In which code is printed using proportional font. Like this:

int z= (*(pPtr))(i+m/k);

In programming, any single symbol matters. That’s why all programming IDEs use monospace fonts:

int z= (*(pPtr))(i+m/k);

The first snippet is much harder to read. Also, it is not the case of “it is just the test, it worth the effort, so stop bitching and read the bloody code”. It does not worth the effort. In the industry, only monospace fonts are used for the code. Every symbol matters, therefore all symbols must be of exactly the same width. To read the code the is printed in proportional font, you really have to look so hard it hurts.

I should also mention meaningless questions. Such as when you are asked something like “what is the standard name for basic_filebuf<char>”. No C++ guru will be able to answer this, except by accident. As it is not something you have to remember to be a C++ programmer. And chances are, you’ll never have deal with that basic_filebuf template.

There also is another type of questions that their authors tried used to evaluate something completely irrelevant. For example, some time ago I did that BB test and I was asked the question above. It was the only question (of 40) that had any C++ templates in them. At the end of the test I was told that I did not have enough competence in templates. How could they figure this out I don’t know? Trust me, I know C++ templates. My colleagues sometimes tell me I know them a little bit too well.

I could go for ages (I did not even mention virtual inheritance questions yet!), but I think I have already said enough. It’s time to summarize.

Imagine yourself in my shoes. You are not a graduate. You are a professional that uses this programming language since you can’t even remember when. You speak that language. You know its tricks. You know its best practices. And you are required to take a test, which:

• Created by people that are far less competent then you are
• Created by people that, probably, never worked in software development
• Has no relation to the real job you are doing now
• Is unrelated to what you will be doing on that job
• Is inconclusive
• Contains errors in either questions or answers. Or both
• Has bugs in implementation

All it means that you have pretty good chances of failing this test, no matter how brilliant you are. Simply because you click on the answer that you know is correct, but test thought it was incorrect.

Your time is wasted, and your application is marked “incompetent in C++”. And this mark is set by someone who doesn’t event know the difference between a reference and a pointer! And, in most cases, you have no chances to prove your innocence, because nobody listens to you.

I can’t speak up for everyone, but I don’t want to risk my reputation in that way. I don’t want to watch my experience and my knowledge being flushed down the toilet. This is why I don’t take any online tests.

If you are an agent who get here by the link in my resume, please note: if sitting such test is your requirement or your customer requires it, I will not be interested. I know my business. The software I developed works in a lot of places. It is unlikely that you will ever notice  it, but you have pretty good chances of being served by some of the systems I build. I won’t name them here (you have my resume, it is all there). I am not afraid of challenge. I love challenge. I desire challenges. That’s what I love most in my work. But the test that you are likely to offer is not a challenge. It’s a Russian roulette. And I won’t play it. Chances of losing playing it do not depend on how good I am, and I do not take such risks. I better lose this exciting opportunity this time.

Пару дней назад на кывте случился очередной срач о собеседованиях и обязательно присущих им горах фудзи, гномах с людоедами и прочими мешками разнокалиберных шаров. Дескать, если не знаешь, как взвесить Боинг – то ты вообще не программист, а совсем даже лох педальный и все в таком духе.

Посмотрел я на этот срач свысока, вспомнил острые тупые ощущения от не очень давнего хождения по собеседованиям, оглянулся на свой опыт и с сожалением отметил, что индустрия разработки ПО переживает серьезную эпидемию, и добрая половина занятых в этой индустрии уже поражена фудзиямой головного мозга в терминальной стадии.

Вот совсем недавний эпизод на работе. Купили мы у одной компании библиотечку одну.  В сырцах. Компания солидная, в нашей области очень хорошо всем известная, да с репутацией годами наработанной. Радовались мы библиотечке как дети, ибо делала она все, что нам нужно было и даже больше, и работало все как из пушки. Знай себе, подтаскивай данные да откачивай результаты.

Заметили мы, правда, бажок за библиотекой. Не баг, а так, сущая ерунда. С кем не бывает. Ну подумаешь, память слегка попортит. То тут объектик расстреляет, то там в прямо в кучу кучу всякого вывалит. Дело житейское. Баг-то ерундовый, да случись нам выпустить продукт с этим багом внутрях, клиенты наши такого йумора бы не поняли, в связи с чем были бы нам и варфоломеевская ночь и утро стрелецкой казни в одном флаконе с кондиционером.

Написали мы аффтарам библиотечки и стали ждать ответа. Ждать ответа нам надоело довольно быстро и примерно через недельку мы решили, что неплохо было бы как-нибудь развлечь себя и всех вокруг. Поэтому мы стали пытать библиотечку люто. Пытали-пытали, да и выяснили, как именно так заинтересовавший нас подземный стук происходит и в какой бубен нужно стукнуть, чтобы его вызвать. Обрадовались мы, да и снова написали аффтарам. Глядите, говорим, баг у вас вот здесь, вот тут, а вон там вообще рыбу заворачивали.

На этот раз аффтары ответили очень быстро. Ух ты, был ответ, и правда бага. Аффтары передавали всяческих регардсов, обещали все починить вот прямо “завтра” и были таковы. Таковыми они оставались следующие три недели.

Через три недели мы получили новую, улучшенную версию библиотеки с банановым вкусом. Красота – память больше не портит. Правда, в улучшенной версии обнаружились парочка доселе невиданных теперь уже утечек памяти и race condition, но кого ж такая фигня в наше время волнует?

В IT индустрии в очередной раз случился перекос. Сейчас модно считать гномов на собеседованиях, но почему-то библиотеки, купленные нами за сто тыщ миллионов, продолжают портить память и тихо дедлочить сами себя. Все кругом могут прикинуть количество заправочных станций в Соединенных ША, но сроки проектов как проваливались, так и проваливаются. Требование уметь определить фальшивую монету за два взвешивания уже стали стандартом, а сплошь и рядом попадаются квадратичные, а то и экспоненциальные алгоритмы там, где сложность вообще может быть константной.

Посмотришь на то, как нынешние собеседования проводятся и сложится полное ощущение, что среднестатистический разработчик ПО – исключительно гений, способный навскидку прикинуть количество лиственных деревьев в лесу на юге Йоркшира с относительной ошибкой в пол-процента, а также обладающие сокровенным знанием неортодоксальных методов взвешивания Боингов. С другой стороны, среднестатистическая программа как была полным багов УГ лет десять назад, так им и остается. С той лишь разницей, что десять лет назад программам не удавалось засрать четыре гига оперативки по причине отсутствия наличия этих самых гигабайтов.

А мораль тут простая. Читать тоже нужно уметь. “Как передвинуть гору Фудзи” не дает советов о том, как следует нанимать сотрудников. Она лишь приводит примеры различных подходов к собеседованиям, принятых в разных компаниях. При этом там неоднократно упоминается, что умение человека щелкать головоломки говорит лишь о том, что он умееть щелкать головоломки. Больше оно не говорит ничего. Умение человека решать кроссворды вовсе не означает, что он будет блестяще проектировать модули системы. Тайное знание причин, по которым крышки к канализационным люкам делаются круглыми, не гарантирует того, что человек сумеет отличить ссылку от указателя. И так далее.

Знаете что? Если бы я хотел разгадывать кроссворды, я бы пошел работать охранником.  Но мне нравится моя профессия, и задачи мне приходится решать гораздо более обширные и серьезные, нежели любой из фудзиямовских ребусов. Которые, кстати, и сами по себе кривые, и ответы к ним тоже не выдерживают никакой критики.

Это даже не УГ, это намного хуже.

А когда-то вполне себе рулезная штуковина была.

#define true false    // happy debugging!

Не совсем такую, но несколько человеко-дней Щасливой отладки доставили. Дело в том, что хотя коллеги и подложили свинью, оптимизатор компилятора сделал все возможное, чтобы нам не было скучно ее искать.

Система наша не то чтобы старая. Политкорректно выражаясь, можно сказать, что она имеет историю. И, как в приличных домах, состоит из ядра и множества внешних компонентов, поставляющих данные в систему. Компоненты эти общаются с ядром через свой собственный несложный API и могут быть написаны вообще кем угодно и на чем угодно. Что и случалось раньше и даже по сей день случается.

Как это всегда случается с системами, имеющими историю, в один прекрасный момент стало ясно, что чего-то в имеющемся API не хватает. В нашем случае оказалось, что если всего лишь одна из функций научится принимать еще всего лишь один дополнительный параметр, то нам всем сразу наступит очень много нирваны и нам, может быть, от этого даже перепадет некоторое ненулевое количество ништяков.

В целях сохранения совместимости с историей системы (то есть, чтобы не переписывать и перетестировать все  тысячи внешних компонентов и не заставлять делать это сторонних вендоров, имевших несчастье компонент этот написать), было принято благоразумное решение оригинальную функцию не трогать, а рядом с ней объявить вторую такую же, с расширенным списком параметров. Соответственно, старые компоненты будут по-прежнему обращаться к старой функции, которая, в свою очередь, будет уже внутри ядра вызывать новую функцию со значением по умолчанию для нововведенного параметра.

Скоро код пишется, да не скоро митинг кончается. В общем, код отрефакторили, написали, начали тестировать, да и к нам прибежали. Дескать, не работает компонент наш. Ага, тот самый, который ни ухом ни рылом в новом API, поскольку написан был три года назад.

Делать нечего, натравили отладчик на систему. Натравили и втроем уставились в монитор, ибо вместо ожидаемого стека вызовов нашим глазам предстало ничего.

По идее, наш компонент, сидючи в своей dll, должен был вызывать функцию_ядра() с набором параметров. В новой системе эта функция ядра передавала вызов в функцию_ядра_второй_версии() вместе со своими параметрами,  в качестве значения нововведенного параметра подсунув некое ЗНАЧЕНИЕ_ПО_УМОЛЧАНИЮ.

По крайней мере, это следовало из кода программы. На деле же в дизассемблированном листинге релизной версии программы тело функции_ядра() состояло из одной-единственной инструкции ret. То есть функция_ядра() в новой версии системы не делала ровным счетом нихрена.  (Отладочной версии по определенным причинам под рукой не было, прим. автора)

Чезанаха искали долго. Сначала уволили отладчик студии. Потом приняли на работу обратно, так как windbg показал то же самое. Потом потрошили настройки проекта на предмет вдруг чего куда-нибудь не туда прилинковалось (при определенном радиусе кривизны рук и не такое может случиться).

Потом вся надежда иссякла. И в этот поворотный момент нам на помощь пришел я. Мне почему-то смутно казалось, что чудес все-таки не бывает и оптимизатор, наверное, имел какие-то определенные причины, побудившие его полностью похерить вызов функции_ядра_второй_версии(). Оказалось, не казалось. Помните, я упомянул, что старая функция просто вызывает новую со ЗНАЧЕНИЕМ_ПО_УМОЛЧАНИЮ для нового параметра? Так вот,  функция_ядра_второй_версии() начиналась ни с чего-нибудь, а с проверки этого параметра. Примерно вот так:

void kernel_function_ver_2(int param, int newParam)
{
    if (newParam != ЗНАЧЕНИЕ_ПО_УМОЛЧАНИЮ)
    {
        //lots of useful stuff
    }
}

Короче, в случае значения по умолчанию для нового параметра новая функция не делала ровным счетом нихрена. Умный компилятор, пытаясь проинлайнить вызов функции, это дело просекал и выкидывал собственно вызов чуть более, чем полностью.

В отладочной сборке мы, конечно, никакой такой чехарды с исчезающим кодом не увидели бы. Но тогда это был бы совершенно рядовой баг, о котором я бы и не подумал написать.

А мораль тут простая – надо, <censored> всегда писать <censored> автоматизированные тесты, <very censored>! Особенно, <multiple censored> если расширяете API, сохраняя обратную совместимость. Простейший юнит (5 минут на написание) или функциональный тест (25 минут на написание) для старой функции указал бы на косяк при первой же компиляции. Но теста не было и случилось то, что случилось – баг вылез в виде совершенно неожиданного спецэффекта в компоненте, который вообще к проблеме отношения не имел, а для его локализации в новом коде и собственно возвращения кода на доработку ненулевому количеству весьма занятых людей потребовалось на весьма ненулевое время напрячь серое вещество. Хотя подобных блох компьютер прекрасно мог бы ловить сам, если бы кому-то не было лениво писать автоматические тесты.

Но за удобство приходится платить. В данном случае расплачиваться приходится невозможностью реализовать отписку. И причина тому банально проста. Вот простейший пример

class Subject
{
   public:
       typedef std::tr1::function<void (const MyData&)> typeDelegate;

       void Subscribe(typeDelegate);
       void Unsubscribe(typeDelegate);
}

Реализация метода Subscribe() вопросов не вызывает. А вот с отпиской возникает проблема. В случае с классическим обсервером в оба метода передается голый указатель на интерфейс подписчика. А указатели можно сравнивать без хитростей, поэтому отписка превращается в банальное удаление элемента из контейнера.

Function сравнивать нельзя. В tr1 этот класс не определяет операторы сравнения, да и сама идея сравнивать функции в общем виде выглядит несколько нелепо. Идея подобного функционального объекта состоит в том, чтобы единожды его создав, скрыть его внутренности от всех остальных, при этом предоставив возможность создавать копии и выполнять как функцию с предопределенной сигнатурой. Эта идея не подразумевает возможности сравнивать, так как непонятно, что тут вообще можно сравнить. В бусте вроде пытались сделать оператор равенства для функций, но ничего хорошего из этого не вышло.

Отсутствие возможности сравнивать ставит жиирный такой знак вопроса на самой возможности отписки. Конечно, можно усложнить интерфейс субъектов и обязать подписчиков передавать какой-нибудь уникальный идентификатор при подписке и отписке. Таким идентификатором, например, может быть и указатель на подписчика, совсем как в классическом обсервере.

Делать так можно. Только это кривовато сразу по нескольким статьям. Поэтому нам нужно пойти другим путем.

Вышеозначенный делегат можно создавать динамически и заворачивать в умный указатель. А умные указатели уже можно сравнивать! Значит, получим

class Subject
{
   public:
       typedef std::tr1::function<void (const MyData&)> typeDelegate;
       typedef std::tr1::shared_ptr<typeDelegate> typeDelegatePtr;

       void Subscribe(typeDelegatePtr);
       void Unsubscribe(typeDelegatePtr);
}

Теперь, чтобы подписаться на события субъекта, подписчик должен сначала динамически создать объект типа typeDelegate, завернуть его в shared_ptr, а затем уже этот умный указатель использовать для подписки и отписки:

// Somewhere in subscriber's constructor, for example
Subject::typeDelegatePtr m_Delegate(
    new Subject::typeDelegate(bind(&Subscriber::Process, this, _1))
    );
//...
//   Subscribe for events on _pSubject
_pSubject->Subscribe(m_Delegate);
//
//
//   Unsubscribe from _pSubject
_pSubject->Unsubscribe(m_Delegate);

При этом реализация методов подписки и отписки субъекта становится очевидной, поэтому о них больше ни слова.

Как видно, если у объекта есть необходимость отписки, он должен сохранять оригинал делегата для этих целей. Если отписка не требуется (а такое бывает часто), локальная копия m_Delegate не нужна – временный экземпляр его можно будет создать при вызове Subscribe().

Можно еще сделать следующий финт ушами – слегка изменить интерфейсы и в субъект передавать не shared_ptr, а weak_ptr, образованный от оригинального умного указателя на делегат, который является членом класса-подписчика. При этом бесплатно решается проблема курицы и яйца: иногда требуется обеспечить, чтобы объект-подписчик автоматически отписывался при удалении, но никакой гарантии, что субъект еще жив, нет и быть не может. Достаточно лишь обеспечить, чтобы субъект проверял, не протухли ли “слабые” указатели (или делал им lock()) перед вызовом делегата, а подписчик владел оригинальным shared_ptr<typeDelegate>. При этом удаление подписчика будет вызывать инвалидацию всех инстанций weak_ptr, образованных от этого указателя, тем самым делая невозможным вызов убитого объекта через делегат, что и даст нам такую вожделенную возможность подписчика замести все свои следы даже без информации о том, на события каких объектов он подписан и живы ли они еще.

Я подозреваю, что этот трюк будет работать только для однопоточного приложения. В ближайшее время я собираюсь детально разобраться с возможными проблемами многопоточности при использовании данного подхода.

Стандарт (а TR1 – это де-факто уже стандарт) – это всегда хорошо. Больше нельзя называться C++ программистом и закатывать истерики при виде безобидного bind. Теперь нужно либо напрячь мозги и таки освоить основы функциональщины, либо идти заниматься гуевой мышевозней.

А еще стандарты – это плохо. Потому что любое, даже самое разумное и оправданное изменение стандарта превращается в процесс перемещения и горы и Магомета к единому стандартизированному месту встречи. И стандартно занимает до чертиков времени, да и других восполнимых и не очень ресурсов тоже дофига требует.

Вот включили они bind в стандарт. И чо (что, шо, So what, нужное подчеркнуть)? А перегруженные операторы не включили! Бо не было их еще в бусте на момент подачи черновиков в стандарт. В итоге в TR1 вот так вот не сделать:

vector<Person> myVector;
//
// Some stuff here
//
vector<Person>::iterator iter = find_if(
myVector.begin(),
myVector.end(),
bind(&Person::GetLastName, _1) == "Pupkin");

А все из-за того, что тот bind, что в TR1, не перегружает оператор “==”, сцуко такой! В итоге, чтобы сделать то же самое, что на куске кода вверху, нужно городить двухуровневый bind с equal_to посередине, от вида которого даже у привычных к boost пассажиров может случится истерика:

vector<Person>::iterator iter = find_if(
myVector.begin(),
myVector.end(),
bind(equal_to<string>, "Pupkin", bind(&Person::GetLastName, _1)));

Еще можно по-старинке взять и нарисовать функтор. На каждый подобный чих. В итоге от обилия их изжога начнется уже у меня.

Нинавижу.

А следующего стандарта еще 10 лет ждать.