On Thursday 24 April 2008 12:38:51 Daniel James wrote:
2008/4/24 Jens Seidel <jensseidel@users.sf.net>:
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...) 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@roedu.net "Linux is obsolete" -- AST