А если, к примеру, мы не нашли ни модель, ни

тип, и хотим вывести код об ошибке в консоль, мол ничего не найдено?

как вариант - добавить вариант TypeInfo.WrongInput какой-нибудь

switch(result) { case TypeInfo::CarInfo: std::cout << "CarInfo"; break; case TypeInfo::CarModel: std::cout << "CarModel"; break; default: std::cout << "Error"; break; }

плюс enum в том что его можно использовать в switch case

https://gieseanw.wordpress.com/2018/12/29/stop-reimplementing-the-virtual-table-and-start-using-double-dispatch/

ну на каждый чих визитор делать тоже не надо)

Пусть почитает. Полезно будет. А там уже решит что ему нужно в его задачах

а кто-то видел это на практике где-то?

Дабл диспатч известная тема

Я видел сотни енамов и ф-й GetType() в проде) И был мягко говоря не в восторге

Окей, посмотрю

ну да

Особенно когда тебе нужно делать диспатчинг в больше чем 1 месте и у тебя эта сотня свит-кейсов по всей кодовой базе

Ну тут так же сотня методов в визиторе

Но не сотня свитч-кейсов в каждой ф-и где приходит объект с иерархии

А такого я никогда не видел

enum class AnimalType { Dog, Cat, Chicken }; struct Animal { AnimalType GetType(); }; void ProcessAnimal(const Animal& animal); void PrintAnimal(const Animal& animal); Ну приходится в каждую ф-ю которая принимает Animal тащить свитч-кейс

для этого существует наследование и полиморфизм

Ну я лишь говорю о том что видел)

Но с наследованием то же самое получится. Просто будешь касты делать. (Если не юзать дабл диспатч)

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

Это абстрактный пример

Это не важно, можно хоть трипл диспатч придумать

ну типа не совсем

Я не помню нормальных историй где реально нужен был даункаст в функции

Я работал на проекте где такого навалом. И виртуальных ф-й GetType() и диспатчингов и всего самого лучшего

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

ну я вот вчера использовал для такой задачи есть такой вот типа код - MCInst - базовый тип для эмиссии машинного кода - в нем по сути содержатся байты без всякой доп информации std::unique_ptr<MCInst> ins; ins = emitter.emit(*ctr); но для некоторых операций есть аппаратные ограничения которые неплохо бы проверять, они(если есть) добавляются в класс - наследник MCInst и в валидаторе мы пробуем сделать каст к этому классу - и если он получается - проверяем для него рестрикшены if (not Validator::validate(ins)) { return false; }

Почему в базовый класс не вынести функцию просто? Либо сделать базовый класс "операция с ограничениями", насладник вашего супер общего класса

разделение ответственности

Да, потому я думаю что операции с ограничениями это другой базовый класс