Хорошо, заголовок вопроса был своего рода крючком. Я уже понимаю, что нет никакого стандарта C ++ ABI. Тем не менее, я не обманул вас, нетерпеливых собирателей голосов. Мне интересно, есть ли какие-либо ограничения для C ++ ABI. Например, кажется распространенным, по крайней мере, название искаженного класса где-то в имени ABI.
Более четкий вопрос
Допустим, у меня есть хеш-функция без столкновений для всех строк. Скажем так, GCC добавил еще один шаг к искажению имен: добавление хеша текущего искаженного имени в подчеркивание. Это сломало бы почти все под солнцем, но будет ли GCC по-прежнему соответствовать стандартам C ++, как это было раньше?
РЕДАКТИРОВАТЬ:
Хорошо, по-видимому, бит «явный вопрос» был своего рода плохо выбранным названием подраздела. Я действительно хотел узнать больше о любых общих стандартах ABI, которым следуют люди. Это было связано с существованием двоичных файлов, которые я компилировал с Mingw32, которые успешно связывались с двоичными файлами, которые я компилировал с MSVC.
Он по-прежнему будет соответствовать стандарту ISO C ++, который даже не упоминает искажение имен в нормативном тексте, не говоря уже об ограничении способов его выполнения, но не будет соответствовать кросс-поставщику. Стандарт ABI что GCC использует для большинства платформ.
Стандарт намеренно об этом молчит: все, что касается ABI и искажения имен, зависит от конкретной реализации. Я полагаю, что ближе всего к информации по этому вопросу:
7.5 / 1 [dcl.link]
Все типы функций, имена функций с внешней связью и переменные
имена с внешней связью имеют языковую связь. [ Заметка: Некоторые из
свойства, связанные с объектом с языковой связью
специфичны для каждой реализации и здесь не описаны. За
Например, конкретная языковая связь может быть связана с
конкретная форма представления имен объектов и функций с
внешняя связь или конкретное соглашение о вызовах и т. д. — конец
нота ]
Таким образом, каждая реализация свободна что-нибудь он хочет в отношении искажения имен, пока искаженные имена действительны в базовой ОС.
Да, это, конечно, будет соответствовать стандартам. Тем не менее, как бы это ни было здорово — соответствовать стандартам, это, конечно, не конец и не конец.
Такое изменение буквально нарушило бы обратную совместимость для каждой отдельной библиотеки или приложения, написанного на C ++ и скомпилированного с использованием указанной версии GCC. Обратная совместимость невероятно важна для разработчиков GCC, и они проводят довольно много времени в списках рассылки (только посмотрите), обсуждая относительную выгоду даже невероятно незначительных изменений ABI перед лицом такой поломки. Часто они идут на все, чтобы предложить обходные пути, которые могут сохранить обратную совместимость.
Что-то говорит мне, что большинство дистрибутивов отказались бы от обновления, если бы они изменили эту политику. Могу заставить их перебраться даже …
По крайней мере, мы могли быть уверены, что они добавят еще один -f
опция, которая отключит новую «функцию».