The Problem

Если ваш компилятор попадает в категорию "недостаток", следующая действующая метапрограмма MPL не будет компилироваться для вас:

#include <boost/mpl/apply.hpp>
using namespace boost::mpl;
template< typename T > struct add_const
{
    typedef T const type;
};
typedef apply1< add_const<_1>,int >::type t; // t == int const

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

The Solution

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

#include <boost/mpl/apply.hpp>
#include <boost/mpl/aux_/lambda_support.hpp>
using namespace boost::mpl;
template< typename T > struct add_const
{
    typedef T const type;
    BOOST_MPL_AUX_LAMBDA_SUPPORT(1, add_const, (T))
};
typedef apply1< add_const<_1>,int >::type t; // t == int const

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

Limitations

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

Чтобы выражение лямбда работало без частичной специализации шаблона и параметров шаблонного шаблона, MPL должен реализовать какой-то другой способ разъединения дерева экспрессии шаблонных инстанциаций, и единственный способ сделать это - через интрузивный механизм интроспекции метафункций. Вот что скрывается заBOOST_MPL_AUX_LAMBDA_SUPPORTМакро мы видели выше.

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

Другими словами, механизм работает до тех пор, пока ваша метафункция является "заполнитель-безопасный" (можно безопасно инстанцироваться на аргументах заполнителя), что сводится к двум критериям:

1. Метафункция не имеет доступа к вложенным членам своих аргументов.
2. Единственными доступными членами являются типы, названные::tagили::тип(заполнители содержат их).

Если эти два держатся, вы можете безопасно положить.BOOST_MPL_AUX_LAMBDA_SUPPORTвнутри вашей метафункции и забудьте о проблеме. Если нет, то вам не повезло, и вам, вероятно, придется написать класс метафункций.

Хорошей новостью является то, что большинство собственных метафункций MPL иBoost. Шаблоны Type Traitsявляются "безопасными для владельца места" и к ним применяется обходной путь, поэтому даже на сломанных компиляторах вещи"просто работают" примерно в 90% случаев использования.

Пожалуйста, обратитесь к справочному руководству MPLдля получения подробной информации о.BOOST_MPL_AUX_LAMBDA_SUPPORTМакро.