Re: [boost] ABI and API compatibility

From: dizzy (dizzy_at_[hidden])
Date: 2008-04-24 08:06:12

On Thursday 24 April 2008 12:38:51 Daniel James wrote:
> 2008/4/24 Jens Seidel <jensseidel_at_[hidden]>:
> >  > http://svn.boost.org/trac/boost/changeset/44440
> >
> >  Is this really a problem? It affects only a private header file in
> >  detail/ no user should use. The changelog isn't very verbose but
> >  "Disable sync use for arm and hppa." could be justified if the previous
> >  code was just buggy or unsupported (no need to keep the some compilation
> >  bug for a new version as in the old one).
>
> Well, I don't know the story behind that change, but if the 1.35
> version compiles then it means that different parts of the program
> will use different implementations of the counter object, which I
> assume are incompatible. 

Actually directly using some class that changes implementation details 
(private members are added, modified, deleted) without recompilation of all 
involved parts leads to violation of ODR and thus UB.

I think KDE people have gone through this alot 
(http://techbase.kde.org/index.php?title=Policies/Binary_Compatibility_Issues_With_C%2B%2B) 
and they even made a document explaining techniques and policies how to 
achieve good ABI compatibility and as you can see in there they advise to use 
the "d-pointer" which seems to me to be another name for the PIMPL idiom. 
Clearly boost will never accept to add an additional layer of indirection for 
all the separately compilable API just to achieve good ABI compatibility.

> I might have made a terminology mistake and was writing about more
> than just ABI compatibility. A simple example: if I made a change to
> Boost.Hash that caused it to return different hash values, then
> different parts of the program would be generating different hash
> values which would cause problems if they accessed the same hash
> table. But I don't think it would break ABI compatibility. And we
> don't have any tests that would detect something like that. That one
> is pretty obvious, but I worry that there might be more subtle
> problems.

Good point, while strict ABI compatibility means you can replace your library 
with compiled code and it should work it does not also mean it will properly 
do so.

-- 
Mihai RUSU					Email: dizzy_at_[hidden]
			"Linux is obsolete" -- AST