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