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
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
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
-- Mihai RUSU Email: dizzy_at_[hidden] "Linux is obsolete" -- AST
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk