abi — Существуют ли инструменты для проверки, не нарушат ли изменения в классе C ++ предыдущую версию этого класса?
Если вы некоторое время программировали на C ++, вы, вероятно, запустили программу, которая потерпела крах «без видимой причины», чтобы выяснить, что ABI библиотеки больше не был совместим, и все, что вам нужно было сделать, это перекомпилировать программное обеспечение с новая версия библиотеки.
Причина, по которой разрывы ABI многочисленны: изменение в виртуальной таблице, добавление / удаление конструкторов, деструктора или переменных-членов …
Что мне интересно, так это: есть ли инструмент, который можно использовать для сравнения двух определений классов (старая версия и текущая версия) и сказать мне, совместимы ли они с ABI или нет.
Это было бы полезно для определения версии моего проекта (то есть, если ABI изменился, я должен был перейти с 1.2.7 на 1.3.0, если ABI не изменился, я просто перейти к 1.2.8).
Многие люди, которые программируют на C ++, имели эту проблему. Хорошим примером является Qt, который ясно заявляет, что патчи не нарушат бинарную совместимость (хотя время от времени они допускают ошибку, но в целом их код довольно солидный).
http://qt-project.org/wiki/Qt-Version-Compatibility
http://qt-project.org/faq/answer/is_qt_binary_compatible
Однако в Qt есть сотрудники, которые могут потратить время на проверку (все вручную?) Того, что публичные классы не изменились таким образом, чтобы нарушить совместимость. Я не могу сказать так много о многих гораздо меньших проектах C ++.
Решение
На линуксе есть аби-податливость корректор инструмент. Его можно использовать для проверки обратной двоичной совместимости вашей библиотеки C ++. Смотрите примеры отчетов инструмента для библиотеки Qt: http://abi-laboratory.pro/tracker/timeline/qt/
Вам нужно скомпилировать отладочную версию вашей библиотеки с дополнением -g -Og опций и дамп ABI вашей библиотеки с помощью аби-самосвал инструмент. Затем сравните два дампов ABI разных версий, чтобы сгенерировать отчет об изменениях ABI.
Другие решения
Формально, если вы изменили токен в определении класса,
они не совместимы В противном случае … я не знаю ни одного инструмента,
так как большинство людей не приняли бы риск, если они изменились
что-нибудь. И так как большинство людей будут использовать make или что-то
похоже, в любое время что-нибудь меняется в заголовке (в том числе
исправляя ошибки в комментариях), они будут автоматически
перекомпилируйте все источники, которые включают заголовок, напрямую
или косвенно.
Единственная проблема возникает, если вы играли с
временные метки файлов. И ответ на этот вопрос: не делай этого.
Наконец, для управления версиями я меняю версию (видна
вне моей собственной структуры сборки) каждый раз, когда я изменяю что-либо
может изменить интерфейс. И я искажаю номер версии
в пространство имен библиотеки, поэтому вы не можете связать код с
неправильная версия библиотеки. Но это действительно только необходимо
если вы доставляете библиотеку и заголовки другим людям.
(И, вероятно, даже тогда — большинство программистов, которых я знаю,
автоматически делать чистую сборку всякий раз, когда они обновляют
библиотеки, которые они используют.)
detector