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

The стандарты кодирования LLVM Кажется, ответить на этот вопрос довольно хорошо:

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

Что сказал, кода LLVM делает широкое использование самодельных виде библиотеку RTTI, которые используют шаблоны, как Иса литой, и dyn_cast. Эта форма RTTI является опцией и может быть добавлена в любой класс. Это также существенно более эффективно, чем dynamic_cast.

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

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

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

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

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

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

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

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

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

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

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

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