1

In particular, the way most C++ implementations work implies that a change in the size of a base class requires a recompilation of all derived classes.

This statement is from stroustrup book. So if base class is in a .so file and we just change a member function implementation, then does it mean that we don't have to recompile my program linked to that shared object?

iammilind
  • 68,093
  • 33
  • 169
  • 336
JamesWebbTelescopeAlien
  • 3,547
  • 2
  • 30
  • 51

3 Answers3

3

Formally, if you don't recompile you're violating the One Definition Rule, and get undefined behavior.

Practically, as long as the member function you modify hasn't been inlined anywhere, and you aren't changing the signature, you probably retain binary compatibility. On most platforms. If you're lucky, your platform documentation provides such a guarantee.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • It isn't clear from the question whether the function implementation is in the header as an inline definition, or in a separate source file that users of the class only see in object form. If the former, assume it has been inlined. If the latter, it probably won't be. –  Feb 08 '12 at 06:52
0

I believe your understanding is correct. Just changing the body of a member function doesn't change the amount of space required for an instance of that object. The code isn't stored "in" the object instance; only the data is.

When the class is compiled, references to member data fields are just offsets from the beginning of that object data. And derived classes' data are typically placed after the base class's data. So if you add a field to the base class, the correct offsets for the derived class data have all changed, which implies the base class needs recompiled, to point to the new (correct) offsets.

Before

class Foo {
    int a;              // offset 0 (assuming no vtable)
}

class Bar : public Foo {
    int b;              // offset 4
}

Bar bar;  bar.b = 7;    // sets the 32-bit value at this+4 to 7

After

class Foo {
    int a;              // offset 0
    int c;              // offset 4
}

class Bar : public Foo {
    int b;              // offset 8
}

Bar b;   bar.b = 7;     // Without recompiling: sets the 32-bit value at this+4
                        //   which is actually where Foo.a is stored!
                        // With recompiling: sets the 32-bit value at this+8
Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
-1

If it just the implementation, it should work fine. That's whole concept of Windows DLL's. Adding or removing interfaces won't changes the class size (unless you're introducing a new virtual function) but in the large extend the way functions laid out in the memory could be changed. So a recompilation is required if you're making use of the new function. On the other hand, most of the modern compilers are smart enough to identify the relevant changes because of a simple modification in the header files.

sarat
  • 10,512
  • 7
  • 43
  • 74
  • "On the other hand, most of the modern compilers are smart enough to identify the relevant changes because of a simple modification in the header files." Could you elaborate? For C++, I haven't seen a compiler yet that checks how header files have changed. At best, after integration with a build system, they check whether the header file has changed at all. –  Feb 08 '12 at 07:03
  • It's not in all cases, though it compiles I have seen with Microsoft compilers reporting "No changes" in the output window. – sarat Feb 08 '12 at 10:38
  • 1
    No, Windows DLLs have nothing to do with C++ classes or inheritance. – Ben Voigt Feb 08 '12 at 14:57