Fragile Binary Interface Problem

Refactored from FragileBaseClassProblem:

The FragileBinaryInterfaceProblem (that is especially common in CeePlusPlus) is as follows: Developer A writes a base class, intending it to be derived from. Developer B uses a library from A containing said base class, and writes and uses a derived class. Developer A delivers to B a newer version of the base class which is supposedly backwards-compatible, having only a minor change (such as a new read-only method). Developer B installs the library from A, relinks (or reloads) his application, and it crashes and burns in mysterious ways. B curses C++ (or whichever language), recompiles, and things work fine.

That's the FragileLanguageProblem?. CeePlusPlus is known to need to recompile everything at least daily.

The problem is that in languages such as C++ which use techniques such as simple offset calculations for data members and simple VeeTable calculations for virtual functions, even a simple change such as adding a function will cause the derived class code to use incorrect offsets. (There are lots of other implementation details that most C++ implementations require derived class code to know about base classes). Many places and systems which do distributed or incremental development in C++ have long lists of rules about which transformations to a base class are "safe" (won't require derived classes to be recompiled) and which aren't. When derived class code is in the hands of a customer who cannot or will not recompile (ie an EndUser); the FragileBinaryInterfaceProblem is a "big" problem; as the customer has software that once worked, doesn't now, and he doesn't know why. (See also DllHell.)

Other languages, such as JavaLanguage and CsharpLanguage, use other techniques for member access (lookup by name, name hashing, etc.) to avoid this problem. The tradeoff can be performance, however DynamicCompilation can completely eliminate any performance penalty.

C++ tends to sacrifice robustness for performance, other languages make the opposite tradeoff. (And the LanguageBigots? in both camps will loudly claim that this is why all but their favorite language is unsuitable for any software development whatsoever.)

The FragileBaseClassProblem, on the other hand, is language-independent; it occurs when a base and a derived class both make assumptions about the behavior of the other that are violated when one (or the other) changes; the most damaging case is when a base class provided by a vendor or other entity changes, breaking someone's derived class. This version of the problem is an OO-design problem, not a language implementation problem; recompiling the code won't help.

-- engineer_scotty (ScottJohnson)

A different, but related problem with CeePlusPlus is that there is (for many platforms) no standardized binary interface for the representation of objects, which means that attempting to link to C++ classes in separate modules (or static-link libraries) that are written using different compilers (or perhaps even different versions of the same compiler) will not work. The ComponentObjectModel is one attempt to address this on the MicrosoftWindows platform, and there are others as well. -- MikeSmith

Many Unix platforms, including LinuxOs, now have standardized on a C++ ABI. Of course, on many such platforms 99% of the world uses GCC, so inter-complier compatibility isn't a major issue--except when dealing with code compiled with older (pre 3.0 mainly) versions of GCC.

It's also somewhat inaccurate to describe COM as a solution to the C++ ABI problem. C++ objects are not necessarily COM objects--COM supports C and VisualBasic as well. Many C++ features such as MultipleInheritance are not supported by COM; COM provides introspection features (like IUnknown::QueryInterface) not supported natively by C++. That said, COM was certainly a useful technology for the Windows platform.

I said "an attempt to address", not "a solution for".

It wasn't clear whether the comment below applied to the FragileBaseClassProblem or the FragileBinaryInterfaceProblem. Possibly both.

Oddly enough, these are almost verbatim the arguments presented for the kind of versioning implemented in CsharpLanguage. To the extent it is mentioned in the partial spec, section 1.17 could be lifted verbatim and placed on this page (and on BinaryCompatibility).

-- StevenNewton