Does changing the order of class private data members breaks ABI

Question

I have a class with number of private data members (some of them static), accessed by virtual and non-virtual member functions. There's no inline functions and no friend classes.

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

Does changing the order of private data members breaks ABI in this case?

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

Edit
The types are not changed, only the order of the members. No bit flags are used as well. The code is used as shared library, there's no static linking to this code. I'm on Linux and the compilers are gcc-3.4.3 and gcc-4.1

Answer 1

It might, yes, if for no other reason than that the size of A could be different due to differences in the location and number of padding bytes between the data members.

Answer 2

C++ defines no ABi. The only correct answer here is "It depends on your compiler". The answer is probably yes.

Answer 3

It'll probably break anywhere you have implementations compiled in to more than one binary, because you can end up with two binaries with functions that access differently ordered private members. This includes implementations of virtual functions, because they can have their not-overriden implementations compiled in to multiple binaries as well.

The best way is to use pure virtual functions and expose these as interfaces from a 'host' binary. Then additional binaries do not need an implementation, so they always call the implementation in the 'host' binary, which means no room for inconsistency.

Answer 4

According to KDE Policies/Binary Compatibility Issues With C++ you cannot do it without breaking binary compatibility. However, as their disclaimer states, some of the advices they give in "you cannot..." part are compiler dependent, so you might get away with that change (although it's not very likely).