[c++] Работа с вектором разных типов одного парента

[Tema]

Привет всем.

Ситуация:
на вход получаем блоки данных. По определенным признакам создаем указатель на объект нужного типа(все типы имеют общего родителя) для каждого блока и скалдывваем все указатели в один вектор родительского типа.
Затем перебираем вектор и взависимости от типа(параметр на классе) вызываем определенные методы(для каждого класса - свои) используя приведение поинтера к нужному типу.

Я влез в этот код и чистые указатели заменил на shared_ptr, т.к. были проблемы с памятью.
Остается вариант shared_ptr.get() и приведение к нужному типу чистого указателя. Без этого, понятное дело, shared_ptr будеи иметь тип родительского класса и про никакие чайлдовые методы он не слышал.

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


Ззаранее спасибо!

[Bizdelnick]

А сделать виртуальный метод, который будет делать то, что надо, для каждого класса, не вариант?

[Tema]

А сделать виртуальный метод, который будет делать то, что надо, для каждого класса, не вариант?

там несколько методов может быть на класс. вызываются для получения определенных данных.
ну типа есть класс Круг. у него два метода: getCenter(), getDiameter(), getColor(). Для класса КриваяЛиния будут методы для получения контрольных точек и узлов.ну и там еще разные методы для схожих классов. Всё загнать в один метод никак не получится, к сожалению.

[Bizdelnick]

Мало что понял, описание слишком абстрактное. Можно конкретный пример: что на входе, что на выходе? На выходе ведь в какой-то точке для всех классов должно быть одно и то же, правильно? То есть в примере с кругами/кривыми, скажем, битмап или svg. Почему не сделать метод toBitmap, внутри которого будет вся обработка нужных данных?

[Olej]

Я влез в этот код и чистые указатели заменил на shared_ptr, т.к. были проблемы с памятью.

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

Ззаранее спасибо!

Заранее пожалуйста.

[NickLion]

Не слушайте насчёт умных указателей, можете спокойно использовать std::shared_ptr, они не привязаны жёстко ни к какому типу, для приведения типов используйте std::dynamic_pointer_cast (ну, или в другой задаче std::static_pointer_cast, std::const_pointer_cast).

Пример, да, желательно. Непонятно что такого Вы хотите сделать в цикле, что абсолютно разное по смыслу для каждого объекта. Почему не сделать виртуальный метод, который по смыслу будет делать то, что должно быть написано у Вас в цикле и вызывать нужные методы, а в цикле его дёргать?

[Tema]

Не слушайте насчёт умных указателей, можете спокойно использовать std::shared_ptr, они не привязаны жёстко ни к какому типу, для приведения типов используйте std::dynamic_pointer_cast (ну, или в другой задаче std::static_pointer_cast, std::const_pointer_cast).

Пример, да, желательно. Непонятно что такого Вы хотите сделать в цикле, что абсолютно разное по смыслу для каждого объекта. Почему не сделать виртуальный метод, который по смыслу будет делать то, что должно быть написано у Вас в цикле и вызывать нужные методы, а в цикле его дёргать?

спасибо за шаблоны!
Правда разницы между ними так и не вразумил. информация на cplusplus.com не исчерпывающая.

Я прикинул, что в принцпе, почти на все классы кроме одного ляжет виртаульный метод, а исключение сделаю if'ом, всяко лучше чем switch в лупе
Пример такой что ничего не покажет - архитектуру разрабатывал джун, вроде меня, попутно изучая APIшки, я лучше попробую переделать под виртуальный метод, а там может еще патернов куда-нить присуну

Спасибо всем за помощь.

[NickLion]

Разница аналогична dynamic_cast, static_cast, const_cast, поэтому, её особо не расписывают.