Давайте забудем про шаблоны. Покажите как вы обрабатываете неизвестные типы на старом добром С++.

А вот и да.
Это создние объекта. А следующие скобки уже будут вызывать оператор ().

Почему, это компилируется компилятором С++?

В реализации совсем другого посетителя to_double_advance проблем никаких нет 

Вопрос стоял по-другому. Есть шаблонный внешний код, который использует внутри посетителя to_double, он нас всем устраивает, но необходимо чтобы он работал и для пользовательского типа MyData.
С MyData можно выполнять любые определения и специализации, а вот внешний код или посетителя менять нельзя. Предположим, что посетителя нельзя подменить и через параметры шаблона.
Вопрос, есть ли способ определить такого посетителя to_double?

К сожалению QVariant абсолютно также плохо работает с пользовательскими типами - ни приведения, ни конвертации. Работает нормально только для базовых типов и типов Qt.

И тогда же вам посоветовали переписать его на С++, переделав структуру в дерево классов, каждый из которых выполняет заданную операцию. Что позволило бы полностью уйти от switch и упростить процесс добавления операций, исключив типичные ошибки с добавлением обработки в один switch и забыванием добавить в другой. Но вы же не пишите на С++...
А boost::any здесь никаких принципиальных решений для вас не добавит.

Вот это утверждение входит в разрез с идиалогией визитёрства, на мой взгляд) Идея ведь в том, чтоб дать возможность при изменении задачи, просто подменять соответствующих визитёров)
И более того, когда у нас появляется новый тип (complex, как в примере) мы же должны каким-то образом сообщить визитёру как с ним работать? А если его (визитёра) нельзя менять? И если API какой либо библиотеки, использующей этот механизм, такую возможность перекрывает, то стоит задуматься(


Здесь, наверное,  нет.. Хотя если написать свой moc для этого, то..  

Здесь я согласен, похоже рассматриваемые задачи просто не предусматривают возможности решения с помощью идеологии визитеров).


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

1. Изначально имеется класс, например, boost::any.
2. В добавок к нему реализованы классы фабрик, которые умеют генерировать boost::any.

C++ (Qt)
 
struct AbstractAnyFabric
{
    virtual ~AbstractAnyFabric () {}
    virtual boost::any make () = 0;
};
 
template < typename _Type >
struct AnyFabric : public AbstractAnyFabric
{
    virtual boost::any make ()
    {
        return boost::any( _Type() );
    }
};
 

3. Для каждого типа реализован вызов уникального экземпляра фабрики (singleton)


4. Реализован механизм регистрации фабрик к функциям, например, к

C++ (Qt)
Result foo ( const boost::any & )
 

5. Реализован механизм регистрации отображения любого идентификатора в фабрику.

Механизмы регистрации работают в run-time и предусматривают вызов методов аля qRegisterMetaType.
Вот этот run-time мне как раз не нравится, а решение в compile-time не нашел.

Такая система позволяет легко зарегистрировать и в дальнейшем использовать любую функциональность с boost::any.

Рассмотрим, например, сериализацию. Для этой задачи необходимо зарегистрировать отображения:

 - typeid( _Type ) в AnyFactory< _Type >,
 - AnyFactory< _Type > в уникальный ключ типа,
 - уникальный ключ типа в AnyFactory< _Type >,
 - AnyFactory< _Type > в метод сериализации,
 - AnyFactory< _Type > в метод десериализации.

В момент сериализации:

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

В момент десериализации:

 - зачитываем ключ,
 - для ключа находим фабрику,
 - через фабрику генерируем any
 - для фабрики находим метод десериализации,
 - выполняем десериализацию содержимого any.

Наоборот, это даст однообразность. Если необходимо обеспечивать различное поведение (обработку) для типов REAL и UREAL, ARGB и CRGB во многих ситуациях, то лучше сразу вначале выделить все разнородные классы. И работать уже однообразно (в категориях визитёра) с этим множеством.  

И, кстатии, если все типы уже известны заранее и не предполагается добавление новых, то  более уместен boost::variant..