Делает изменение порядка класса, частные элементы данных повреждают ABI
У меня есть класс с количеством частных элементов данных (некоторые из них статичный), полученный доступ виртуальными и невиртуальными функциями членства. Нет никаких подставляемых функций и никакого друга классов.
class A
{
int number;
string str;
static const int static_const_number;
bool b;
public:
A();
virtual ~A();
public:
// got virtual and non-virtual functions, working with these memebers
virtual void func1();
void func2();
// no inline functions or friends
};
Изменение порядка частных элементов данных повреждает ABI в этом случае?
class A
{
string str;
static const int static_const_number;
int number; // <-- integer member moved here
bool b;
...
};
Править
Типы не изменяются, только порядок участников. Никакие битовые флаги не используются также. Код используется как общая библиотека, нет никакого статического подключения к этому коду. Я нахожусь на Linux, и компиляторы являются gcc-3.4.3 и gcc-4.1
4 ответа
Может, да, если не по какой-либо другой причине, кроме того, что размер A может быть разным из-за различий в расположении и количестве байтов подстановки между членами данных.
Согласно KDE Policies/Binary Compatibility Issues With C++ вы не можете сделать это без нарушения бинарной совместимости. Однако, как говорится в их отказе от ответственности, некоторые советы, которые они дают в части "вы не можете...", зависят от компилятора, так что вы можете обойтись без этого изменения (хотя это маловероятно).
C++ не определяет ABi. Единственный правильный ответ здесь - "Это зависит от вашего компилятора". Скорее всего, ответ положительный.
Это, вероятно, сломается везде, где есть реализации, скомпилированные в более чем один двоичный файл, потому что в итоге вы можете получить два двоичных файла с функциями, которые обращаются к приватным членам в разном порядке. Это относится и к реализациям виртуальных функций, поскольку их не переопределенные реализации могут быть скомпилированы в несколько двоичных файлов.
Лучший способ - использовать чистые виртуальные функции и открывать их как интерфейсы из "главного" двоичного файла. Тогда дополнительные двоичные файлы не нуждаются в реализации, поэтому они всегда вызывают реализацию в "главном" двоичном файле, что означает отсутствие места для несогласованности.