Каково общее представление о расширениях отражения в std :: type_info?

Question

Я заметил, что рефлексия - это одна из особенностей, которую разработчики из других языков испытывают недостаток в c ++. Для некоторых приложений я действительно понимаю, почему! Намного проще написать такие вещи, как автозаполнение IDE, если у вас есть отражение. И, конечно же, API-интерфейс сериализации стал бы проще, если бы он у нас был.

С другой стороны, один из основных принципов c ++ - не платить за то, что вы не используете. Что имеет полный смысл. Это то, что я люблю в C ++.

Но мне пришло в голову, что может быть компромисс. Почему компиляторы не добавляют расширения в структуру std::type_info? Не было бы времени выполнения. Двоичный файл может оказаться больше, но это может быть простой переключатель компилятора для включения / выключения, и, честно говоря, если вы действительно беспокоитесь о экономии места, вы, скорее всего, отключите исключения и RTTI.

Некоторые люди ссылаются на проблемы с шаблонами, но компилятор успешно генерирует std::type_info структур для типов шаблонов.

Я могу представить себе переключатель g ++, такой как -fenable-typeinfo-reflection, который мог бы стать очень популярным (и такие распространенные библиотеки, как boost / Qt / etc, могли бы легко иметь проверку для генерации кода, который использует его, если таковой имеется, и в этом случае конечный пользователь выиграет не дороже, чем щелкнуть выключателем). Я не считаю это необоснованным, поскольку такие большие переносимые библиотеки уже зависят от расширений компилятора.

Так почему же это не распространено? Я полагаю, что я что-то упустил, какие технические проблемы с этим?

РЕДАКТИРОВАТЬ: Всего несколько метрик перебазировать аргумент:

Я посмотрел на довольно большой проект Qt (около 45 000 LoC) и измеряет размер метаобъектов. Я считаю, что это разумный показатель, потому что система Qt moc является довольно исчерпывающей системой отражений (типы, функции, перечисления, члены и некоторые конкретные понятия Qt, такие как «свойства»). Всего было 67 метаобъектов , так что нет ничего сложного, но ничего сумасшедшего, , что в сумме составляет 5479 байт Однако почти все они были 32-байтовыми или менее (, самый большой из которых составлял 1427 байт ). Учитывая, что современные компиляторы производят двоичные файлы размером более 4 КБ даже для самой простой программы, эти цифры не возмутительны). Хотя я бы хотел, чтобы что-то подобное было применено к STL, чтобы увидеть, как оно выглядит справедливо.

Answer 1

Вместо того, чтобы навязывать мне определенный подход к отражению во время выполнения, я предпочел бы иметь возможность компилировать время, которое я мог бы использовать для генерации необходимой мне информации.

Таким образом, мне не пришлось бы платить за информацию, которой я на самом деле не пользуюсь, и мог бы использовать метапрограммирование для создания необходимого кода взаимодействия без дополнительных шагов перед сборкой или какого-либо сложного декларативного EDSL.

Каспин упомянул один из возможных подходов здесь . Честно говоря, я удивлен, что эта тема, кажется, никогда не выдвигалась в качестве предложения для включения в C ++.

Answer 2

Обычно использование отражения свидетельствует о плохой разработке программного обеспечения; правильного использования интерфейсов и полиморфизма достаточно, чтобы делать почти все, что бы вы ни делали с отражением. Если добавить дополнительную информацию в std :: type_info, это действительно приведет к раздуванию программы. Проблема с шаблонами не в том, что вы не можете сгенерировать из них std :: type_info, а в том, что вы можете получить взрыв типов, и поэтому каждое создание шаблона приводит к еще одному объекту std :: type_info, который вам понадобится. Ваше предложение об использовании переключателя компилятора на самом деле не помогает или не имеет смысла ... во-первых, стандарт никогда не будет указывать переключение компилятора, потому что это будет зависеть от реализации, но при условии, что это будет сделано ... что произошло бы, если бы вы хотели использовать отражение с классом из библиотеки, для которой отражение было отключено? Если бы большинство библиотек отключили рефлексию - что они, вероятно, и сделали бы - тогда это серьезно ограничило бы полезность этой функции, а если бы большинство библиотек не отключили ее, вы бы заплатили за нее, не используя ее.

Answer 3

Возможно, множество типов в C / C ++ затрудняет гибкое рефлексивное программирование. Гипотетической базе данных или сериализованному интерфейсу, способному обрабатывать любые примитивные типы, потребуются особые случаи для [unsigned] int, short, [long] long, char, float, [long] double, их массивов, связанных с ними функций и т. Д. к интерфейсу с именем mangler.

Не то чтобы я думаю, что это хорошая причина. Я написал рефлексивный интерфейс SQL в Boost MPL несколько лет назад, и это было хлопотно. Было бы намного приятнее и проще с «нативным» средством.

Я думаю, что большинство людей достигают рефлексии с помощью дополнительной предварительной обработки, такой как генератор интерфейса Apple от Apple и аналогичные инструменты в GNU и Microsoft.

Для меня более удивительным, чем отсутствие поддержки в C ++, является то, что в новых языках, которые стимулируют конкуренцию, таких как D и (в любом случае, в духе) Go.