Объект умеет сам себя рисовать?

[Igors]

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

Учитывая грядущую отрисовку тонн полигонов, вопрос о какой-то "заточке по скорости" здесь не стоит. А достоинства свитча - не столько его быстрота как компактность (не путать с "краткость"). По крайней мере все руление собрано в одном месте, нередко удается запастись общим кодом для неск веток. А расхристанные виртуалы как минимум трудно обозреть.   

Я имел в виду - проверять поле типа и в зависимости от него брать нужные параметры.

Так это по существу сейчас и сделано, конечно можно вместо dynamic_cast оформить ID + switch, но это не принципиально   

Так я насколько понимаю проблему - Igors как раз хочет избежать множества виртуальных Draw.

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

[__Heaven__]

Есть ещё вариант использовать rtti и map

Код

C++ (Qt)
static const std::map<std::type_info, std::function> funMap = {
    {typeid(CObjectParam1), DrawObjectsParam1},
    ....
};

[Igors]

Есть ещё вариант использовать rtti и map

Код

C++ (Qt)
static const std::map<std::type_info, std::function> funMap = {
    {typeid(CObjectParam1), DrawObjectsParam1},
    ....
};

Так надо прилагать усилия чтобы связать каждый DrawObjectsParam_xxx с окном. Плюс заряжать и хранить мапу(ы) - возможно свою для каждого окна. Не вижу где "выйгрыш"

[twp]

Да, виртуальные вызовы не зря напрашиваются  
Этот случай настолько частый, что даже придумали для него паттерн Visitor. Если открыть ссылку и затем ниже пример на C++, то код практически 1 в 1 тот, что предложил Old.

[Igors]

Да, виртуальные вызовы не зря напрашиваются  
Этот случай настолько частый, что даже придумали для него паттерн Visitor. Если открыть ссылку и затем ниже пример на C++, то код практически 1 в 1 тот, что предложил Old.

Не уверен что visitor тут подходящий паттерн. Напр с какой стати каждый из крохотных классов QObjectPatamXX посвящен в подробности мощного CWindow? Чего это ведомые данные что-то решают? Что если напр один из наследников CWindow рисует тот же QObjectPatamXX иначе?

[Old]

Напр с какой стати каждый из крохотных классов QObjectPatamXX посвящен в подробности мощного CWindow?

Это получилось с легкой руки разработчика, который засунул все в класс MainWindow (CWindow).

Чего это ведомые данные что-то решают? Что если напр один из наследников CWindow рисует тот же QObjectPatamXX иначе?

А они ничего и не решают. Они для рисования используют публичные механизмы предоставленные CWindow и если наследник CWindow изменит "рисование", то QObjectPatamXX нарисует ровно тем, что предоставлено.

[__Heaven__]

Напр с какой стати каждый из крохотных классов QObjectPatamXX посвящен в подробности мощного CWindow?

Тема: Объект умеет сам себя рисовать?