Список проблем С++ ABI

Я видел много дискуссий о том, как С++ не имеет стандартного ABI совершенно так же, как и C. Мне любопытно, какие именно проблемы. До сих пор я придумал

  • Название mangling
  • Обработка исключений
  • RTTI

Существуют ли какие-либо другие проблемы с ABI, относящиеся к С++?

Ответ 1

Сверху моей головы:

Спецификация С++:

  • Где можно найти параметр 'this'.
  • Как называются виртуальные функции
    • т.е. использует ли он vtable или другой
    • Какова структура структур, используемых для ее реализации.
  • Как обрабатываются несколько определений
    • Несколько экземпляров шаблонов
    • Встроенные функции, которые не были включены.
  • Объекты продолжительности статического хранения
    • Как обрабатывать создание (в глобальной области)
    • Как обрабатывать создание функции local (как добавить ее в список деструкторов)
    • Как справиться с уничтожением (уничтожить в обратном порядке создания)
  • Вы упоминаете исключения. Но также, как исключения обрабатываются вне основного()
    • т.е. до или после main()

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 четко определенное поведение), он охватывает неопределенное поведение, поведение, определяемое реализацией, поведение, специфичное для локали, и общие расширения.