Что может сделать использование C ++ RTTI нежелательным?

Стандарты кодирования LLVM , по-видимому, достаточно хорошо отвечают на этот вопрос:

В попытке уменьшить размер кода и исполняемого файла LLVM не использует RTTI (например, dynamic_cast <> ) или исключения. Эти две языковые возможности нарушают общий принцип C ++ «вы платите только за то, что используете», вызывая раздувание исполняемого файла, даже если исключения не используются в базе кода или RTTI никогда не используется для класса. Из-за этого мы отключаем их глобально в коде.

Тем не менее, LLVM широко использует ручную форму RTTI, в которой используются такие шаблоны, как isa <>, cast <> и dyn_cast <>. Эта форма RTTI является опциональной и может быть добавлена ​​к любому классу. Он также значительно эффективнее, чем dynamic_cast <>.

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

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

В 64-битной архитектуре (которая сегодня широко распространена), один указатель составляет 8 байтов. Поскольку компилятор создает множество маленьких объектов, это довольно быстро складывается.

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

Их постоянное беспокойство о потреблении памяти окупилось тем, что Clang потребляет значительно меньше памяти, чем, например, gcc, что важно, когда вы предлагаете библиотеку клиентам.

С другой стороны, это также означает, что добавление нового типа узла обычно приводит к редактированию кода в большом количестве файлов, потому что каждый переключатель должен быть адаптирован (к счастью, компиляторы выдают предупреждение, если вы пропустите член enum в переключателе ). Поэтому они согласились сделать обслуживание немного сложнее во имя эффективности памяти.

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

Я не являюсь экспертом в C ++ RTTI, но я также реализовал свой собственный RTTI, потому что есть определённые причины, по которым вам нужно это делать. Во-первых, система C ++ RTTI не очень многофункциональна, в основном все, что вы можете сделать, - это приведение типов и получение базовой информации. Что, если во время выполнения у вас есть строка с именем класса, и вы хотите создать объект этого класса, удачи вам сделать это с C ++ RTTI. Кроме того, C ++ RTTI не является действительно (или легко) переносимым между модулями (вы не можете определить класс объекта, который был создан из другого модуля (dll / so или exe). Точно так же реализация C ++ RTTI специфична для компилятора, и обычно это дорого включать с точки зрения дополнительных издержек для реализации этого для всех типов.Наконец, он не является действительно постоянным, поэтому его нельзя реально использовать для сохранения / загрузки файла, например (например, вы можете сохранить данные объекта в файл, но вы также хотели бы сохранить «typeid» его класса, чтобы во время загрузки вы знали, какой объект создать для загрузки этих данных, что нельзя сделать надежно с C ++ RTTI). По всем или некоторым из этих причин многие фреймворки имеют свой собственный RTTI (от очень простого до очень многофункционального). Примерами являются wxWidget, LLVM, Boost.Serialization и т. Д., Это действительно не так уж редко.

Так как вам нужен виртуальный метод, чтобы иметь vtable, почему бы им просто не пометить мет од виртуальный? Виртуальные деструкторы, кажется, хороши в этом.

Это, вероятно, то, что использует их система RTTI. Виртуальные функции являются основой для динамического связывания (связывания во время выполнения), и, таким образом, оно в основном требуется для выполнения любого вида идентификации / информации типа во время выполнения (не только требуется RTTI C ++, но любая реализация RTTI будет иметь полагаться на виртуальные звонки так или иначе).

Если их решение не использует обычный RTTI, есть идеи, как оно было реализовано?

Конечно, вы можете посмотреть реализации RTTI в C ++. Я сделал свой собственный, и есть много библиотек, которые также имеют свой RTTI. Это довольно просто написать, на самом деле. По сути, все, что вам нужно, - это средство для уникального представления типа (т. Е. Имени класса или его искаженной версии или даже уникального идентификатора для каждого класса), какой-то структуры, аналогичной type_info, которая содержит все информация о типе, который вам нужен, тогда вам нужна «скрытая» виртуальная функция в каждом классе, которая будет возвращать эту информацию о типе по запросу (если эта функция переопределена в каждом производном классе, она будет работать). Есть, конечно, некоторые дополнительные вещи, которые можно сделать, например, одноэлементное хранилище всех типов, возможно, со связанными фабричными функциями (это может быть полезно для создания объектов типа, когда все, что известно во время выполнения, это имя типа, в виде строки или идентификатора типа). Также вы можете захотеть добавить некоторые виртуальные функции, чтобы разрешить динамическое приведение типов (обычно это делается путем вызова функции преобразования самого производного класса и выполнения static_cast до типа, к которому вы хотите привести).