John Plocher wrote:
> Garrett D'Amore wrote:
>> One of the implications of such a binding (Volatile), is that
>> projects which build other C++ shared libraries upon this one cannot
>> have a commitment level higher than Volatile either.
>
> Braap. Bad Architecture Alert. The whole reason we provide abstractions
> like consolidations and components is precisely so that we can provide
> "higher than Volatile" expectations for things that theselves may exhibit
> "less than Volatile" stability.
>
> There is no reason this couldn't be made a part of the KDE consolidation,
> and maintained by them as Committed interfaces for use by any KDE
> consumers
> who need it. Volatile means "can change", not "will change", and both
> the
> Apache C++ Lib and the KDE projects certainly seem to meet the basic ARC
> expectations of managing the compatible evolution of their component.
>
> If the C++ basis that KDE builds upon were to change incompatibly, I'd
> expect KDE to react by producing a major release - again, just like the
> ARC would expect.
>
> Nothing here requires KDE to be Volatile.
We're not talking about something that is delivered with Consolidation
Private binding... we're talking about (assuming Volatile binding)
something that could change underneath KDE. Such a change would be
devastating to binary compatibility for applications linking against KDE
C++ libraries.
If KDE has a way to shield applications underneath from such a binary
breakage, then its a different story altogether. However, my
understanding is that in this case (unlike more simple cases involving
only C), there isn't a way for KDE to do that.
I.e. with C++ code, if application #include's a KDE header, which itself
#include's a libstdc++ header, the binary bits of the application
*very* likely contain details of the underlying libstdc++ implementation
encoded in them.
C++ is reasonably good at providing good programmatic boundaries between
interface and implementation at the *source* code level. However, it
falls down completely at the *binary* level. (Which isn't to say that
libraries simply *can't* prevent this sort of problem -- merely that the
expectation should *not* be that they do, because it will probably
require some rather grotesque contortions on the part of the library to
do so.)
Now, if the library (KDE) never #include's "standard" C++ headers
(provided by this library) in its own headers (that it exports to
applications), but only uses them in .cxx (or .cpp or .C or whatever)
implementation files, then I agree that there is no problem. (Although
the consuming application may itself still wind up needing to have its
own dependency upon the libstdc++, but that issue is largely orthogonal
as far as something like KDE is concerned.)
To put this in comparison, imagine if almost all of the standard C
functions were simply *macros* rather than functions, and the macros
made references to volatile innards of the C library. While the *API*
might be "clean" and safe, the *ABI* would most certainly not be. This
is the situation that we're in with C++, I think.
-- Garrett
