Ответы (56)
-
дак надо же тогда узнавать какого конкретно класса пришел указатель, даункаст чтоли ? Гуголь не одобряет даункасты
-
ну это и есть даункаст, херня же, не известно как там кресты RTTL реализуют, может как всегда ад и содомия
-
Кошерно в ООП объявить методы в интерфейсе и в потомке их реализовать по-разному.
-
вообще, на ум приходит структура с перечислением, указывающим тип и union объединяющий разные структуры.
-
ну понятно, что придется менять базовый класс, а значит и ВСЕ наследники, но ведь это и есть ADT компилятор тебе покажет где там не хаватает методов в наследниках чтобы обработать новые типы сообщений корректно (или проигнорировать явно), да, нужен доступ к сиходному коду, зато безопасненько.
-
А вообще твой визитор можно нагенерить шаблонами.
-
Первое решение это базовый класс, три наследника и даункаст или виртуальные методы реализующие все необходимые функции над твоим типом сообщения. На гугл забей. Этот метод очевидным образом плох поскольку любой четвёртый наследник базового класса тоже валиден.
Второй вариант — тип-перечисление. Если коротко, то возьми boost::variant./9 · Ответить -
Визитор это ж просто паттерн, а даункаст это механизм языка. Или что-то поменялось за это время?
-
нет, этот просто паттерн можно просто применить чтобы избавиться от даункаста и добавить проверки на стадии компиляции
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));
