Идиомы С++. Static visitor

Тут стоит подчеркнуть, что у паттерна Посетитель есть две независимые стороны
— разнести алгоритм работы с контейнером и алгоритм работы с элементом
— реализовать мультиметод (произвольный тип приёмника, произвольный тип посетителя)

И вокруг мультиметодов в С++ хватает идиом, благо, мы можем возложить задачу диспетчеризации
— на алгоритм обхода (сделав его полиморфным — тот же std::for_each — времени компиляции, или ::qsort — времени исполнения)
— на аргументы мультиметода (двойная диспетчеризация по-ООПшному с виртуальными функциями, по-сишному с перебором тэгов, или вообще без двойной диспетчеризации, сразу по парам тэгов)

Такой взгляд позволит нам отстроиться от жёстких канонов:
Алгоритм контейнера может передавать посетителя элементам, а может передавать элементы посетителю.
В общем-то, разницы нет.
Будет там IVisitor::send(IData*) --> IData::receive(TheVisitor*) --> TheData::receive(TheVisitor*),
или наоборот, IData::send(IVisitor*) --> IVisitor::receive(TheData*) --> TheVisitor::receive(TheData*)
или сразу, launch(ILeft*, IRight*) --> land(TheLeft*, TheRight*)

Суть паттерна в том, что у нас есть много независимых объектов-посетителей и много сгруппированных объектов-данных, и алгоритм, позволяющий передружить одного посетителя со всеми данными.
Из того, что посетители не сгруппированы, мы ослабляем требования к их типу. То есть, посетителям очень естественно быть полиморфными без ограничений, а полиморфность данных — это уже по обстоятельствам (фиксированный тип, фиксированный вариант, произвольная иерархия).
В противном случае мы получаем другой паттерн — сигналы-слоты, когда однотипные аргументы рассылаются коллекции полиморфных приёмников.
Ну а раз так, то диспетчеризацию удобно начинать с интерфейса посетителя, IVisitor::send(IData*), где IData полиморфный или нет.

Опять же, кто знает, — нужно в данном конкретном месте посетителю знать конкретные типы своих аргументов, или нет?
Если, например, посетитель тупо считает количество визитов, то мультиметод (посетитель, данные) сведётся к простому (посетитель, void*).
А в случае с boost::variant ситуация немножко другая. Если уж посетитель полез в него, — то, наверно, не просто так; и тем более, что данные заведомо полиморфны. Поэтому двойная диспетчеризация начинается сразу с приёмника.

Зачем в этом классе метод accept?

class person_t
{
public:
    person_t(const std::string& name, size_t age)
        : name_(name), age_(age){}

    template<typename Visitor>
    void accept(Visitor& v) {v.visit(*this);}
    size_t age() const {return age_;}
private:
    std::string name_;
    size_t age_;
};

Он же нигде не используется.

struct person_visitor_t
{
    person_visitor_t(size_t age_limit) : age_limit_(age_limit){}
    bool operator()(const person_t& p) {return visit(p);}
    bool visit(const person_t& p) {return p.age() < age_limit_;}
    size_t age_limit_;
};

Это структуру можно немного переделать:

struct person_visitor_t
{
    person_visitor_t(size_t age_limit) : age_limit_(age_limit){}
    bool operator()(const person_t& p) {return p.age() < age_limit_;}
    size_t age_limit_;
};

И ничего не изменится, станет только короче и понятнее.
Что-то не вяжутся у меня предикаты STL и visitor.

В .NET в этом плане все прозаичнее и double dispatch толком не нужен.