Question

In my library there’s a class like this:

class Foo {
public:
    void doSomething();
};

Now, implementation of doSomething() has been grow a lot and I want to split it in two methods:

class Foo {
public:
    void doSomething();
private:
    void doSomething1();
    void doSomething2();
};

Where doSomething() implementation is this:

void Foo::doSomething() {
    this->doSomething1();
    this->doSomething2();
}

But now class interface has changed. If I compile this library, all existent applications using this library wont work, external linkage is changed.

How can I avoid breaking of binary compatibility?

I guess inlining solves this problem. Is it right? And is it portable? What happen if compiler optimization uninlines these methods?

class Foo {
public:
    void doSomething();
private:
    inline void doSomething1();
    inline void doSomething2();
};

void Foo::doSomething1() {
    /* some code here */
}

void Foo::doSomething2() {
    /* some code here */
}

void Foo::doSomething() {
    this->doSomething1();
    this->doSomething2();
}

EDIT:
I tested this code before and after method splitting and it seems to maintain binary compatibility. But I’m not sure this would work in every OS and every compiler and with more complex classes (with virtual methods, inheritance…). Sometimes I had binary compatibility breaking after adding private methods like these, but now I don’t remember in which particular situation. Maybe it was due to symbol tabled looked by index (like Steve Jessop notes in his answer).

Answer 1

Strictly speaking, changing the class definition at all (in either of the ways you show) is a violation of the One Definition Rule and leads to undefined behavior.

In practice, adding non-virtual member functions to a class maintains binary compatibility in every implementation out there, because if it didn’t then you’d lose most of the benefits of dynamic libraries. But the C++ standard doesn’t say much (anything?) about dynamic libraries or binary compatibility, so it doesn’t guarantee what changes you can make.

So in practice, changing the symbol table doesn’t matter provided that the dynamic linker looks up entries in the symbol table by name. There are more entries in the symbol table than before, but that’s OK because all the old ones still have the same mangled names. It may be that with your implementation, private and/or inline functions (or any functions you specify) aren’t dll-exported, but you don’t need to rely on that.

I have used one system (Symbian) where entries in the symbol table were not looked up by name, they were looked up by index. On that system, when you added anything to a dynamic library you had to ensure that any new functions were added to the end of the symbol table, which you did by listing the required order in a special config file. You could ensure that binary compatibility wasn’t broken, but it was fairly tedious.

So, you could check your C++ ABI or compiler/linker documentation to be absolutely sure, or just take my word for it and go ahead.