Вариации на тему STL. Адаптер обобщенного указателя на функцию-член класса

Я думаю, большинство из тех, кто использует C++ согласятся, что STL – это хорошо. Это удобная, легкая, хорошо переносимая библиотека, которая прекрасно расширяется и не содержит решений, которые были сделаны только в силу вкусов кого-либо из авторов. В этом она совпадает по духу с основным принципом C++, провозглашенным Бьярном Страуструпом в своей книге «Дизайн и эволюция C++» – никогда и никому не навязывать ничего насильственно. Но не все так гладко – часто приходится добавлять в библиотеку возможности, не предусмотренные стандартом. Иногда при этом также

приходится бороться с неполной совместимостью компиляторов со стандартом C++.

Представим себе некий объект, который имеет перегруженную операцию operator->. Мы можем его представить себе как некий обобщенный указатель, который не является указателем в полном смысле этого слова, но «прикидывается» им. Мы можем использовать его для доступа к полям и методам некоего объекта. Можно придумать много разных применений для обобщенных указателей: реализация различных вариантов умных указателей, осуществляющих некоторую форму сборки мусора или просто ведущих статистику обращений к объектам, можно использовать обобщенные указатели для реализации паттерна «Proxy», когда мы вместо объекта используем обобщенный указатель на него, а сам объект прячется где-либо из соображений инкапсуляции, можем использовать их для реализации стратегий ленивых и сверхэнергичных вычислений и для многого другого. Видно, что обобщенные указатели – весьма полезная штука.

СОВЕТ Для того, чтобы понять всю мощь и красоту обобщенных указателей весьма полезно почитать такие книги, как «Эффективное использование C++» и «Наиболее эффективное использование C++» Скотта Мейерса, «C++: библиотека программиста» Джеффа Элджера, а также более общую книгу «Приемы объектно-ориентированного программирования. Паттерны проектирования» Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса.

Обобщенный указатель всего лишь «прикидывается» указателем и не может быть использован везде, где используются обычные указатели. Например, возьмем адаптер указателя на функцию-член класса из STL:

Видно, что когда мы вызываем mem_fun(some_class::some_member), то получаем функциональный объект, который принимает указатель (обычный!) на объект класса some_class и вызывает функцию some_member по этому указателю. Но что будет, если мы попытаемся вызвать operator с аргументом – обобщенным указателем на объект класса A, если у этого указателя нет неявного преобразования в указатель на объект класса?

ПРИМЕЧАНИЕ Такие объекты-заместители бывают нужны, если клиенту нельзя

давать доступ к самому объекту: например, если тот размещен в специальной области памяти и его адрес может меняться после сборки мусора.

Для начала обратим внимание на то, что mem_fun_t::operator принимает только указатель на объект класса, чьим членом является функция pm. От этого было бы неплохо избавиться. Рассмотрим такой вариант:

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

Теперь все хорошо – при необходимости вызвать operator для специфичного обобщенного указателя сгенерируется своя функция operator.

Рассмотрим реализацию mem_fun_t:

Все кажется идеальным для работы с указателями, но ведь обобщенный указатель – это не указатель, он не знает, что такое operator->*! Нужно явно узнать, на какой объект он ссылается и потом уже выполнять операцию ->*

Правда, возникает другая одна проблема – если теперь мы захотим использовать наш адаптер с обычным указателем, то потерпим поражение: обычные указатели не понимают operator->. Таким образом, нам необходимо специализировать нашу функцию operator для работы с обычными указателями: