Привет, Хабр.

Одним прекрасным пятничным вечером я писал обработку ошибок в одном своем хобби-проекте… Так, это вступление для другой статьи.
В общем, одним прекрасным пятничным вечером мне потребовалось пройтись по boost::variant и что-то сделать с лежащими там данными. Вполне себе стандартная задача для boost::variant, и каноничный (но очень многословный) способ её решения — описать наследующуюся от boost::static_visitor структуру с перегруженными operator() и передать её в boost::apply_visitor. И вот этим прекрасным вечером мне почему-то стало очень лень писать всю эту кучу кода, и захотелось заиметь какой-то более простой и краткий способ описания визиторов. Что из этого вышло, можно почитать под катом.

Так вот, каноничный способ выглядит как-то так:

using Variant_t = boost::variant<int, char, std::string, QString, double, float>;

template<typename ValType>
struct EqualsToValTypeVisitor : boost::static_visitor<bool>
{
    const ValType Value_;

    EqualsToValTypeVisitor (ValType val)
    : Value_ { val }
    {
    }

    bool operator() (const std::string& s) const
    {
        return Value_ == std::stoi (s);
    }

    bool operator() (const QString& s) const
    {
        return Value_ == s.toInt ();
    }

    template<typename T>
    bool operator() (T val) const
    {
        return Value_ == val;
    }
};

void DoFoo (const Variant_t& var)
{
    const int val = 42;
    if (boost::apply_visitor (EqualsToValTypeVisitor<int> { val }, var))
        // ...
}

И это мы ещё воспользовались тем, что четыре случая для int, char, float и double можно описать одним шаблонным оператором, иначе операторов было бы ещё на три больше, код был бы ещё более раздутым, и выглядело бы всё ещё более ужасно.

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

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

void DoFoo (const Variant_t& var)
{
    const int val = 42;
    const bool isEqual = Visit (var,
            [&val] (const std::string& s) { return val == std::stoi (s); },
            [&val] (const QString& s) { return val == s.toInt (); },
            [&val] (auto other) { return other == val; });
}

Оказывается, можно.

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

Моей первой попыткой, в детали реализации которой я вдаваться не буду (но которую можно потыкать здесь), было запихивание всех лямбд в std::tuple и последовательный их перебор в шаблонном operator() собственного класса, их хранящего, пока не удастся вызвать какую-нибудь функцию с аргументом, переданным самому operator().

Очевидным недостатком такого решения является фатально некорректная обработка типов, приводимых друг к другу, и зависимость от порядка передачи лямбд в функцию создания визитора. Так, рассмотрим упомянутый выше Variant_t, имеющий среди прочих int и char. Если он создан с типом char, а в функцию создания визитора первой была передана лямбда, принимающая int, то она же первым делом и вызовется (и успешно!), а до случая для char дело не дойдёт. Причём эта проблема действительно фатальна: для тех же int и char невозможно (по крайней мере, без существенных извращений) так определить порядок лямбд, чтобы для и int, и char передавались туда, куда надо, без всяких преобразований типов.

Однако, теперь стоит вспомнить, что такое лямбда и во что она разворачивается компилятором. А разворачивается она в некоторую анонимную структуру с переопределённым operator(). А если у нас есть структура, то от неё можно отнаследоваться, и её operator() автоматически окажется в соответствующей области видимости. А если отнаследоваться от всех структур сразу, то все их operator()'ы попадут куда надо, и компилятор автоматически выберет нужный оператор для вызова с каждым конкретным типом, даже если типы друг в друга приводятся (как в упомянутом выше случае int и char).

А дальше — дело техники и variadic templates:

namespace detail
{
    template<typename... Args>
    struct Visitor : Args...        // да, тут тоже можно разворачивать variadic pack
    {
        Visitor (Args&&... args)
        : Args { std::forward<Args> (args) }...        // и тут можно
        {
        }
    };
}

Попытаемся написать функцию, которая берёт boost::variant и набор лямбд и посещает этот самый variant:

template<typename Variant, typename... Args>
auto Visit (const Variant& v, Args&&... args)
{
    return boost::apply_visitor (detail::Visitor<Args...> { std::forward<Args> (args)... }, v);
}

Оп, получили ошибку компиляции. apply_visitor ожидает получить наследника boost::static_visitor, по крайней мере, в моей версии Boost 1.57 (говорят, позже была добавлена поддержка автоматического вывода возвращаемого типа в C++14-режиме).

Как получить тип возвращаемого значения? Можно попробовать взять, например, первую лямбду из списка и вызвать её со сконструированным по умолчанию объектом, что-то вроде

template<typename Variant, typename Head, typename... TailArgs>
auto Visit (const Variant& v, Head&& head, TailArgs&&... args)
{
    using R_t = decltype (head ({}));
    //return boost::apply_visitor (detail::Visitor<Head, TailArgs...> { std::forward<Head> (head), std::forward<TailArgs> (args)... }, v);
}

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

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

Вместо этого мы поступим наоборот. Мы возьмём первый тип из списка типов variant и вызовем наш уже сконструированный Visitor с ним. Это гарантированно должно сработать, потому что визитор обязан уметь обработать любой из типов в variant. Итак:

template<typename HeadVar, typename... TailVars, typename... Args>
auto Visit (const boost::variant<HeadVar, TailVars...>& v, Args&&... args) ->
{
    using R_t = decltype (detail::Visitor<Args...> { std::forward<Args> (args)... } (std::declval<HeadVar> ()));
    //return boost::apply_visitor (detail::Visitor<Args...> { std::forward<Args> (args)... }, v);
}

Однако, сам Visitor должен наследоваться от boost::static_visitor<R_t>, а R_t на этот момент неизвестен. Ну это уж совсем просто решить, разбив Visitor на два класса, один из которых занимается наследованием от лямбд и агрегированием их operator()'ов, а другой — реализует boost::static_visitor.

Итого получим

namespace detail
{
    template<typename... Args>
    struct VisitorBase : Args...
    {
        VisitorBase (Args&&... args)
        : Args { std::forward<Args> (args) }...
        {
        }
    };

    template<typename R, typename... Args>
    struct Visitor : boost::static_visitor<R>, VisitorBase<Args...>
    {
        using VisitorBase<Args...>::VisitorBase;
    };
}

template<typename HeadVar, typename... TailVars, typename... Args>
auto Visit (const boost::variant<HeadVar, TailVars...>& v, Args&&... args)
{
    using R_t = decltype (detail::VisitorBase<Args...> { std::forward<Args> (args)... } (std::declval<HeadVar> ()));

    return boost::apply_visitor (detail::Visitor<R_t, Args...> { std::forward<Args> (args)... }, v);
}

Для совместимости с C++11 можно добавить trailing return type вида

template<typename HeadVar, typename... TailVars, typename... Args>
auto Visit (const boost::variant<HeadVar, TailVars...>& v, Args&&... args) ->
        decltype (detail::VisitorBase<Args...> { std::forward<Args> (args)... } (std::declval<HeadVar> ()))

Приятным бонусом является возможность работы с noncopyable-лямбдами (захватывающими в C++14-стиле какой-нибудь unique_ptr, например):

#define NC nc = std::unique_ptr<int> {}

Variant_t v { 'a' };
const auto& asQString = Visit (v,
            [NC] (const std::string& s) { return QString::fromStdString (s); },
            [NC] (const QString& s) { return s; },
            [NC] (auto val) { return QString::fromNumber (val); });

Недостатком является невозможность более тонкого паттерн-матчинга в стиле

template<typename T>
void operator() (const std::vector<T>& vec)
{
    //...
}

К сожалению, [] (const std::vector<auto>& vec) {} написать нельзя. Повод отправить пропозал к C++17.