Почему использование ключевого слова typeid является плохим дизайном?

Проблема не в typeid. Проблема в том, что typeid побудит вас написать это:

PolymorphicType *pType = ...;
if(typeid(*pType) == typeid(Derived1))
  pType->Func1();
else if(typeid(*pType) == typeid(Derived2))
  pType->Func2();
else if(typeid(*pType) == typeid(Derived3))
  pType->Func3();

Это то, что мы называем «действительно глупым». Это виртуальный вызов функции, выполненный наименее разумным способом. typeid может привести к злоупотреблениям при использовании вместо функций dynamic_cast и virtual.

Этот пример может показаться надуманным. Ведь очевидно же, что это всего лишь виртуальный звонок. Но плохой код часто вырастает из пути наименьшего сопротивления; все, что нужно, это чтобы один человек сделал typeid() == typeid(), и зародыш этого кода уже начался. В общем, если вы часто используете typeid напрямую, велика вероятность, что вы делаете что-то, что можно было бы лучше сделать с помощью других языковых конструкций.

typeid – это последний метод вывода полиморфного типа.

Все ли случаи использования typeid неверны? Конечно нет. boost::any без него было бы невозможно. Что ж, это было бы возможно, но это было бы не безопаснее, чем void*. typeid - это то, что делает возможным безопасное стирание типа boost::any. Есть и другие законные способы его использования.

Но по соотношению количества строк кода к использованию я бы предположил, что это должно быть максимум одна из 10 000 строк кода. Намного меньше, чем это, и вы, вероятно, используете его неправильно.

Медленна ли проверка типов?

В общем, основная причина для вызова typeid либо в шаблонном коде (как в boost::any), либо когда вы ожидаете полиморфный тип. Если тип определен статически (т. е. задано имя типа или значение неполиморфного типа), вы можете ожидать, что это будет сделано во время компиляции.

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

Я не думаю, что кто-то говорит, что использование typeid само по себе является плохим дизайном; скорее вы услышите, что использование typeid свидетельствует о плохом дизайне. Идея состоит в том, что любая логика, которая отличает (скажем) Square от Circle, должна быть в этих классах, поэтому должна быть выражена виртуальной функцией (полиморфизм).

Излишне говорить, что это не абсолютное правило.

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

Все выражения имеют статический тип времени компиляции (после раскрытия шаблона). Все типы либо полиморфны, либо нет.

Я попытаюсь объяснить вам, почему typeid бесполезен в обоих случаях:

1. Нет причин использовать typeid, если статический тип выражения не является полиморфным. Компилятор будет использовать статический тип, а не динамический, поэтому работает перегрузка функций во время компиляции. А идентичность типа можно проверить намного эффективнее, используя шаблонную черту типа, такую ​​как is_same.

2. Если статический тип выражения является полиморфным, то typeid терпит неудачу. Да, это даст информацию о динамическом типе объекта. Но только самый производный динамический тип. Это нарушает принцип подстановки Лискова, поскольку для заданных типов Base и Child добавление нового типа Grandchild, производного от Child, не будет рассматриваться как Child. Нарушается и принцип Open-Closed, так как дизайн нельзя расширять новыми типами, не переписывая все подряд. Инкапсуляции нет, так как информация об иерархии классов должна быть разбросана по всей программе, создавая сильную связанность. dynamic_cast решает некоторые, но не все из этих проблем.

Короче говоря, программу, использующую typeid, будет очень сложно поддерживать и тестировать.

И, как и в любом правиле, могут быть ограниченные исключения. Где вы используете возможности языка OO наследования и виртуальных функций, но на самом деле вам не нужен полиморфный дизайн. Я могу придумать только один: где вы хотите зарегистрировать имя типа в виде строки, используя type_info::name(). Вы также можете использовать его для обнаружения нарезки (где полиморфизм уже нарушен). Но это хорошо только для отладки, а не для управления ходом программы.