ABI: три весёлых буквы 🫡
Одна из тем, которая мало заметна во внешнем мире, но вокруг которой происходит регулярный shitstorm среди тех, кто двигает C++ - это вопрос слома ABI 😀
ABI (wiki) это гарантии, которым интерфейс программного модуля (библиотека, операционная система) удовлетворяет на бинарном уровне: соглашение о вызове, размер типов данных, и многое другое.
Самый простой пример, когда это важно - когда бинарь (исполняемая программа,
.exe на Windows) требует для работы динамические библиотеки (.dll на Windows или .so на Unix).Бинарь и динамическая библиотека - две разные программы, которые должны быть всегда совместимы друг с другом. Это значит, что бинарь и библиотека должны уметь обновляться независимо друг от друга таким образом, чтобы они могли продолжать работать вместе.
(про работу динамических библиотек можно прочитать в этой статье или в этой книге)
Проблема в том, что ABI очень просто сломать - есть неполный список ломающих изменений. Одни из понятных примеров:
😀 Добавить новое поле в публичный класс
🙁 Ломает вообще всё, потому что теперь у
.exe-файла (который не перекомпилируют!) неправильное смещение стека, размеры зависимых классов и так далее.😀 Добавить новый виртуальный метод
🙁
.exe-файл теперь неправильно вычисляет адреса старых виртуальных методов.Есть тулзы, которые проверяют совместимость ABI: abidiff.
Стандарт C++ развивается так, чтобы не ломать ABI в новых версиях стандарта - то есть чтобы перекомпилирование проекта не мешало использовать зависимые
.dll/.so.Это приводит к проблемам, которые описаны в статьях:
😀 День, когда умерла стандартная библиотека - лонгрид
😀 Цифровые демоны - лонгрид посложнее
Есть два класса проблем, связанные с сохранением ABI:
1️⃣ Нельзя сильно поменять язык, например сортировать поля класса, чтобы класс занял меньше места.
2️⃣ Нельзя нормально менять стандартную библиотеку - большинство пропозалов уничтожаются на месте (проблем этого класса в несколько раз больше).
Реализация стандартной библиотеки C++ не является частью компилятора. Стандарт C++ только определяет интерфейс, а реализаций есть несколько, и они предоставляются в виде динамической библиотеки.
Из-за этого стандартная библиотека C++ крайне бедная, ее контейнеры медленнее чем нужно, некоторые классы супер хреновые (
std::initializer_list, std::regex), и так далее - и никто не может это исправить. Если задизайнить что-то новое (например парсер JSON), это потом нельзя будет нормально поменять.Даже дизайн Win32, POSIX, протоколов Ethernet предполагает всевозможные изменения в будущем - но только не стандартная библиотека C++.
С каждым годом стоимость не-слома ABI (застой в языке) постепенно приближается к стоимости слома ABI. Пока непонятно, будет ли разрешено ломать ABI, так как минимум два вендора против:
1️⃣ GCC. Все коммерческие продукты, поставляемые в бинарном виде для Linux, надеются на неизменность ABI, благодаря чему они могут не пересобирать свой продукт под каждый новый дистрибутив.
2️⃣ Microsoft. Visual Studio с 15 версии сохраняет своё ABI, библиотеки скомпилированные в 2015 версии без проблем линкуются в 2017 и 2019.
Некоторые думают, что C++ "сохраняет совместимость" и это типа хорошо. На деле, как мы видим, причины в сохранении совместимости бизнесовые - чтобы не перекомпилировать продукт кучу раз под разное окружение.
Ведь если подумать логически, ничего хорошего не выйдет, если мы возьмем какую-то библиотеку, скомпилированную ~20 лет назад. Она скорее всего либо собрана под старую архитектуру, либо несовместимым компилятором, и медленной (с каждым годом компиляторы быстрее).
У всех разное мнение по поводу ABI. Я считаю, что если коммерческий продукт активно развивается и хочет идти в ногу со временем, то так или иначе он будет использовать новые возможности языка и библиотеки. И в этом случае он не будет работать на старых дистрибутивах со старыми версиями стандартной библиотеки даже при неизменном ABI.
Программирование с учетом ABI это не самая распространенная бизнес схема. Например, Qt ломает ABI каждый релиз, и никто от этого не умер.
(конец в комментарии)