Список проблем С++ ABI
Я видел много дискуссий о том, как С++ не имеет стандартного ABI совершенно так же, как и C. Мне любопытно, какие именно проблемы. До сих пор я придумал
- Название mangling
- Обработка исключений
- RTTI
Существуют ли какие-либо другие проблемы с ABI, относящиеся к С++?
Ответы
Ответ 1
Сверху моей головы:
Спецификация С++:
- Где можно найти параметр 'this'.
- Как называются виртуальные функции
- т.е. использует ли он vtable или другой
- Какова структура структур, используемых для ее реализации.
- Как обрабатываются несколько определений
- Несколько экземпляров шаблонов
- Встроенные функции, которые не были включены.
- Объекты продолжительности статического хранения
- Как обрабатывать создание (в глобальной области)
- Как обрабатывать создание функции local (как добавить ее в список деструкторов)
- Как справиться с уничтожением (уничтожить в обратном порядке создания)
- Вы упоминаете исключения. Но также, как исключения обрабатываются вне основного()
Generic.
- Расположение точек передачи параметров
- Расположение возвращаемого значения
- выравнивание участников
- Перетяжка
- Зарегистрировать использование (какие регистры сохранены, которые являются царапинами)
- размер примитивных типов (например, int)
- формат примитивных типов (формат с плавающей запятой)
Ответ 2
Большая проблема, по моему опыту, - это стандартная библиотека С++. Даже если у вас есть ABI, который диктует, как должен быть разбит класс, разные компиляторы предоставляют различные реализации стандартных объектов, таких как std::string
и std::vector
.
Я не говорю, что было бы невозможно стандартизировать внутреннюю компоновку объектов библиотеки С++, только это не было сделано раньше.
Ответ 3
Самое близкое, что мы имеем к стандарту С++ ABI, это Itanium С++ ABI:
этот документ написан как общая спецификация, который можно использовать с помощью реализаций С++ > на различных архитектурах. Однако он содержит > специфичный для процессора материал для 64-разрядной ABI Itanium, идентифицированный как например ".
GCC doc объясняет поддержку этого ABI для С++:
Начиная с GCC 3.2, двоичные соглашения GCC для С++ основаны на написанном, не зависящем от поставщика С++ ABI, который был специально разработан на 64-битный Itanium, но также включает в себя общие спецификации, которые применяются на любую платформу. Этот С++ ABI также реализуется другим компилятором поставщиков на некоторых платформах, в частности системах GNU/Linux и BSD.
Как было указано @Lindydancer, вам нужно использовать ту же С++ стандартную libary/runtime.
Ответ 4
Стандарт ABI для любого языка действительно должен исходить от данной платформы, которая хочет поддержать такую вещь. Языковые стандарты, особенно C/С++, действительно не могут делать это по многим причинам, но главным образом потому, что такая вещь сделает язык менее гибким и менее портативным и, следовательно, менее используемым. C действительно не имеет определенного ABI, но многие платформы определяют (прямо или косвенно) одно. Причина, по которой это не происходит с С++, заключается в том, что язык намного больше, и изменения происходят чаще. Тем не менее, у Herb Sutter есть очень интересное предложение о том, как получить больше платформ для создания стандартных ABI и как разработчики могут писать код, который использует ABI стандартным образом:
https://isocpp.org/blog/2014/05/n4028
Он указывает, как С++ имеет стандартный способ привязки к платформе C ABI, но не С++ ABI через extern "C". Я думаю, что это предложение может пройти долгий путь, позволяя определить интерфейсы в терминах С++ вместо C.
Ответ 5
Я видел много дискуссий о том, как С++ не имеет стандартного ABI совершенно так же, как и C.
Какой стандарт C ABI? Приложение J в стандарте C99 составляет 27 страниц. В дополнение к поведению undefined (и некоторые реализации дают некоторое UB четко определенное поведение), он охватывает неопределенное поведение, поведение, определяемое реализацией, поведение, специфичное для локали, и общие расширения.