Garrett is exactly right in his explanation and examples.
I covered most of these points in my paper that I mentioned earlier.
http://developers.sun.com/solaris/articles/CC_abi/CC_abi_content.html
Let me add two comments about inlining.
1. The C++ standard library API includes many tiny functions that are
expected to be inlined in order to get acceptable performance. Except
possibly when compiling in debug mode, every compiler does in fact
inline many functions.
2. At high optimization levels, the Sun compiler optimizer phase might
choose to inline any function, even ones not declared inline, unless you
explicitly ask it not to.
---
Steve Clamage, stephen.clamage at sun.com
On 9/5/2008 4:46 PM, Garrett D'Amore wrote:
> Thank you for your instructional description of the C++ language with
> respect to templates.
>
> There are a few significant points, that I think you keep missing, or
> are glossing over:
>
> When I said C++ doesn't separate *binary* interface from implementation,
> I was *not* talking about the nice separation done for the benefit of
> the programmer. I was talking about separation done across the boundary
> created by the linker ... AFAIK, C++ does not recognize that there is
> such an interface boundary.
>
> In C++, if an inline function is expanded by the compiler, but makes use
> of *private* members of the class, then the *binary implementation* of
> the resulting code is *tied* to the implementation, and if the
> implementation changes (e.g. by changing the dynamically linked library)
> then there can be unfortunate consequences.
>
> I'm not a template expert, so I'll demonstrate with a simple inline
> function using C++ circa 1990.
>
> class box {
> int width;
> int height;
> /* put more private details here... */
>
> public:
> void draw(); // private implementation elsewhere
>
> public inline int getwidth() { return width; }
> };
>
> If this is in header, then the implementation parts (the width, the
> height and their offsets within the class) wind up getting encoded into
> the binary that includes this header. If the width or the height ever
> move (e..g by moving another member in front of them in the class), then
> the binary is busted. Likewise, if the private members change type
> (e.g. from a uint16_t to a uint32_t), breakage ensues.
>
> It is possible to have implementations that don't suffer from this
> problem, but it requires that the implementation refrain from inline
> functions, and take care that the headers *only* expose portions of the
> classes that will never ever change (or change in a way that breaks the
> binary implementation of the class.) I won't endeavor to describe how
> this problem may or may not affect templates, as such is out of my area
> of expertise.
>
> I've not kept up with the C++ standards admittedly, but I believe that
> this aspect of binary compatibility is not one that has been addressed
> in the standards, and likely not in the specification of the libraries.
> It is possible that the Apache product has taken great care to avoid
> this kind of potential breakage, but my first reaction is doubt.
>
> Now, that's only *one* aspect of the "compatibility problem."
>
> There is a grave and other serious problem, which relates to the fact
> that this proposal effectively creates a new baseline (i.e. a new ABI)
> for C++ programs, where programs linked (directly or indirectly) against
> this library are incompatible with our one and only bless (at this time)
> ABI, based on the libC that ships with Solaris today.
>
> And, the project recognizes that future breakage is not just possible,
> but *likely*, when either the compiler team ships another project, or
> when the library needs an update due to changes in the standard.
>
> Imagine the plight of the poor user who downloads a program
> (WhizzyDownloadTracker) which uses two different class libraries. On
> the one hand, it uses the NiftyNetworking library for networking
> functionality, and it uses the KDE libraries for user interface work.
> Well, good thing, the IPS repo contains both NiftyNetworking and KDE.
> Download both, install, and then download, compile (via ./configure) and
> install the WhizzyDownloadTracker. All's good, right?
>
> Well, a few hours later, when the compile for WhizzyDownloadTracker
> finally completes, we find out life isn't so good.
>
> Because you see, the NiftyNetworking set was not built with the Apache
> libstdc++, but instead with the "default" libraries that we have been
> recommending people use for years. The user tries to run the program,
> and if he's lucky, gets a meaningful link error message. In reality,
> the error message, if any, that results is probably completely cryptic
> to the end user, who was just trying to install software. In a worse
> scenario, the program just dumps core mysteriously.
>
> The worst part of the above scenario, apart from the confusion that the
> poor non-C++-developing victim gets to experience, is that he's
> downloaded the foundation libraries from a single source (Sun's IPS
> repo), so they *should* work together, shouldn't they?!?
>
> Too bad.
>
> So now the user complains to the FOSS authors for WhizzyDownloadTracker,
> who are unfamiliar with Solaris (they did their development on Linux,
> see?), and don't know that Solaris has multiple incompatible C++ ABIs,
> nor how to tell which components were built against which ABI.
>
> So, the FOSS author probably gives up, and tells the poor user that he
> needs to recompile the base libraries (either KDE or NiftyNetworking),
> so that they are built with compatible libraries.
>
> At this point, the FOSS author is laughing at Sun and Solaris, and
> probably also cheerfully writes a blog somewhere admonishing folks
> against running Solaris.
>
> And, the original user? He's probably given up. Most likely he either
> he chooses not to use WhizzyDownloadTracker, or winds up giving up on
> Solaris and switches back to Linux or Windows. Either way he's probably
> pretty ticked that "Sun" is delivering crapware that just doesn't work
> together.
>
> I don't know if the above illustration clearly enough paints the picture
> of my features, but I think it certainly demonstrates that we cannot
> just blithely ignore the issue and pretend it won't affect anyone.
>
> -- Garrett
