базовый класс и три наследника

дак надо же тогда узнавать какого конкретно класса пришел указатель, даункаст чтоли ? Гуголь не одобряет даункасты

dynamic_cast или метод gettype, на выбор

ну это и есть даункаст, херня же, не известно как там кресты RTTL реализуют, может как всегда ад и содомия

Кошерно в ООП объявить методы в интерфейсе и в потомке их реализовать по-разному.

вообще, на ум приходит структура с перечислением, указывающим тип и union объединяющий разные структуры.

если по-взрослому — визитор.

точно ! и безопасно вроде и даже быстро

визитор это ад

ну хз, по началу да, а щас вроде понятно все

ты когда его расшитирь попробуешь, держись

ну понятно, что придется менять базовый класс, а значит и ВСЕ наследники, но ведь это и есть ADT компилятор тебе покажет где там не хаватает методов в наследниках чтобы обработать новые типы сообщений корректно (или проигнорировать явно), да, нужен доступ к сиходному коду, зато безопасненько.

А вообще твой визитор можно нагенерить шаблонами.

Забиватор точно такое делал

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

Второй вариант — тип-перечисление. Если коротко, то возьми boost::variant.

а предложенный визитор ?

Визитор это ж просто паттерн, а даункаст это механизм языка. Или что-то поменялось за это время?

нет, этот просто паттерн можно просто применить чтобы избавиться от даункаста и добавить проверки на стадии компиляции
juick.com gist.github.com

Да какой же это тогда ADT? Я могу ADT засунуть в switch в любом месте, а тут даже контекст вызова теряется, или его надо специально параметром объявлять.
Негодно.

фигачишь новый наследник MessageVisitor и засовываешь свой контекст в него.

Ну коли как лямбду, то может и сойдет.
А чтобы без указателей, объявляй параметры как &argName и пользуй temporary.

а разве можно наследников передавать как & ?

А какая разница? (хотя я на плюсах не пишу давно, мне кажется что референсы это те же указатели только сбоку)

проблема в том что когда принимаешь указатель, то он может быть как указателем на экземпляр, так и указателем на наследника класса, а ссылка должна быть конкретного типа, потому что у нее семантика объекта а не указателя. Очень хуевое техническое решение смешивать логику указатель/объект и конкретный класс/любой наследник ясчитаю. Чтобы принять в функцию любого наследника я должен принять указатель, и в этом жопа, потому что указатели надо либо выделять/освобождать, либо давать как ссылку на объект из стека

я добавил коммент к гисту

то что я хотел, атлична

Как лямбду не получится. Разве что передавать лямбдами в MessageVisitor обработчики для разных конструкторов.

Да, вроде жабные анон классы тупая вещь, а поди ж ты. Думал лямбды как-то можно заюзать прямо как их в жабе, хотя естественно нет, в лямбдах же только одна точка входа.

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

ну да, и по очереди навешивать коллбэк за коллбэком

Это же кресты, такое уже не плохо, я считаю

А что мешает сделать у базового класса набор виртуальных методов принимающих колбеки разных типов? И не страдать фигнёй.

Ну вот пришел тебе Message*
и как ты теперь узнаешь какой метод вызвать? У них же будут разные сигнатуры как я понял, то есть тоже самое что тупо много разных методов

тут же вся магия вовсе не в визиторе, а в accept, он же знает какой у него тип this и потому знает какой метод у визитора вызвать, но сам он виртуальный и поэтому полиморфизм

Точно также как и здесь. В конкретном классе передаёшь в колбек this.

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

А ты сейчас в каждый визитор передаёшь сообщения на все случаи жизни. В чём разница?

он создается один раз

Он, это кто?

визитор

Не понял тебя. Ты создаёшь по визитору на контекст.

ну да, контекст то можно создать в инициализации, а потом принимать сообщения одно за другим

gist.github.com — я имел в виду что-то такое.

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

а еще не исключен вариант множественного матчинга, не безопасно

Это вариант не будет работать, если ты получишь указатель на базовый класс.

смотри функцию acceptMessage, она принимает именно его

Твой вариант офигительно запутанный и неочевидный. Имело смысл либо определить в базовом классе интерфейс и реализовывать его в наследниках, либо… если тебе нужен «паттерне-матчинг» то без даункаста ты всё равно ничего не сделаешь. Но вообще тебе скорее всего нужен variant.

без даункаста как раз сделаю, уже сделано же, функция acceptMessage принимает указатель на Message и без даункастов обрабатывается нужное сообщение, плюс, если передам сообщение, которое визитор не обрабатывает, то будет ошибка компиляции.

В классе MessageVisitor нет метода определённого для типа Message. Он работает только тогда когда тебе известен тип сообщения в момент компиляции.

нет

Всё. Понял. Да. Ты прав. Работать будет.

не можешь за одним подсказать, как убрать уродство типа
MoveMessage m(20, 20);
MoveMessage m2(10, 10);
StopMessage m3;
acceptMessage(&m);
acceptMessage(&m2);
acceptMessage(&m3);
?
Надо передать указатель блин, и не охота создавать дурацкие временные объекты

О каких временных объектах идёт речь?

ну да, m1, m2, m3 они же на стеке создаются, и мы передаем указатель на них в acceptMessage, хочется писать в одну строку типа
acceptMessage(MoveMessage(20, 30));

"exist (A or B or C)" :3