Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at