Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30

Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-09-27 22:27:34

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.