On 28/09/2017 03:12, degski wrote:
No proof intended, just examples... For some reason, lack of maintainers, backward (binary) compatibility, things don't progress... And one ends up, like you suggested below, doing ones' own thing.
Boost does not and has never (to my knowledge) guaranteed backwards binary compatibility in general, although it does try to maintain backwards source compatibility (but even that has been broken on occasion when sufficiently justified or just by accident). There are a few exceptions, eg. Boost.Serialization preserves backwards binary compatibility of its serialization archives (but still not necessarily of the code itself). *Some* Boost libraries try to provide a certain amount of ABI protection, where you get link errors instead of erroneous code if you link incompatible compilation units together (eg. where a library is used with different options in each case). Some others try to allow both versions to coexist. Still others don't have any protection and things will just misbehave at runtime in that case. But these are all different from backwards compatibility.
Reason number one is simple, it's this rule: "Thou shall not inherit from class xxx publicly in the absence of a virtual destructor as it effectively prevents you from polymorphic use of descendants.", and this rule is repeated over and over again. boost::pool does not have a virtual destructor (trivial change, I agree, but that was what I was doing in the first place!).
While that's a good rule in general, it only really applies to classes that are actually going to be used polymorphically -- ie. you're passing around pointers to the base class. That's not really likely to be the case for classes in Boost.Pool.