Czy zmiana kolejności członków prywatnych danych klas łamie ABI

Question

Mam klasę z liczbą prywatnych elementów danych (niektóre statyczne), do których dostęp mają wirtualne i nie-wirtualne funkcje składowe. Nie ma żadnych wbudowanych funkcji ani klas przyjaciół.

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 
}; 

Czy zmieniając kolejność członków prywatnych danych łamie ABI w tym przypadku?

class A 
{ 
    string str; 
    static const int static_const_number; 
    int number; // <-- integer member moved here 
    bool b; 
    ... 
}; 

Edit
typy nie są zmieniane, tylko kolejność członków. Nie są również używane żadne flagi bitowe. Kod jest używany jako biblioteka współdzielona, ​​nie ma statycznego linkowania do tego kodu. Jestem na Linuksie, a kompilatory to gcc-3.4.3 i gcc-4.1

Answer 1

Może tak, jeśli z żadnego innego powodu rozmiar różni się o A z powodu różnic w lokalizacji i liczbie wypełniania bajtów między elementami danych.

Answer 2

C++ nie definiuje ABi. Jedyna poprawna odpowiedź tutaj to "To zależy od twojego kompilatora". Odpowiedź jest prawdopodobnie tak.

Answer 3

Prawdopodobnie zepsuje się w dowolnym miejscu, w którym masz zainstalowane kompilacje do więcej niż jednego pliku binarnego, ponieważ możesz otrzymać dwa pliki binarne z funkcjami, które uzyskują dostęp do różnych członków prywatnych. Obejmuje to implementacje funkcji wirtualnych, ponieważ mogą one również zawierać implementacje nieodtwierdzone w wielu plikach binarnych.

Najlepszym sposobem jest użycie funkcji wirtualnych czystych i odsłonięcie ich jako interfejsów z pliku binarnego hosta. Następnie dodatkowe pliki binarne nie wymagają implementacji, dlatego zawsze wywołują implementację w pliku binarnym hosta, co oznacza brak miejsca na niespójność.

Answer 4

Według KDE Policies/Binary Compatibility Issues With C++ nie można tego zrobić bez zrywania kompatybilności binarnej. Jednak, jak stwierdza ich oświadczenie, niektóre porady udzielane w części "nie możesz ..." są zależne od kompilatora, więc możesz uciec z tą zmianą (chociaż to mało prawdopodobne).