Re: [boost] [Booster] Or boost is useless for library developers

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-05-15 22:08:39

Artyom wrote:
> Hello,
>
> I want to bring up an important issue that boost developers are not
> aware of: anybody who develops a library and wants to keep any kind
> of backward compatibility can-not use Boost.

> it is impossible to promise that it would not be broken between
> releases.
>
> Why boost::details::sp_counted_base may be changed because in next
> version atomic counter was implemented using assembly rather then
> pthread's mutex... which affects the layout of
> boost::details::sp_counted_base and thus breaks compatibility.

I've heard this many times and I have to say I'm not getting it.

case I

First let's examine a library implemented as header only.

a) version 0 - a bunch of headers.

User builds his code and is pleased as punch.

b) version 1 - same bunch of headers + plus a few more.
Also the original classes have some new functions - BUT none
of the existing functions are eliminated nor have a change in
interface.

Where is the incompatibility.  What does "binary compatibility"
even mean since the the application doesn't use the new functionality
until it is rebuil? But this can't be a problem.

To my knowledge - I don't think that any libraries deprecate
existing functions nor change thier interface or sematics.  So
I don't understand where this whole thing is coming from

case II

A library that has to be built as either a DLL or a static library.

a) version 0 - bunch of headers and source modules.

User is pleased as punch same as above.

b) version 1 - same as above + changes in function implementation
Now there a library/dll which is different than the one produced by
version 0.

User rebuilds his app against the new library.  It's still going to work
since the newer version has everything the old version does + some more.
Also SUPPOSE that no data members are deleted/added to the header
declarations corresponding to interface classes.

c) User rebuilds his app and sends it to his customers how have the
DLL library built in version 0.  if he's using a static library there's
no problem.  If he's using a DLL the application will run against
the original version DLL with no problem.

Sooo it seems to me that the only situation which would
"break binary compatibility" would be when ALL the following
are true.

i) The library is not a header only library
ii) class definition includes new data members in one or more interface.
iii) one library is distributed separately from it's prequisites

Am I getting this right?  If so it would seem that there's not
much that "breaks binary compatibility" and that it wouldn't
take too much effort to avoid this.

What am I missing here?

Robert Ramey