Boost logo

Boost :

Subject: Re: [boost] Boost.test failures in develop
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-10-05 16:43:05

On 10/5/15 1:20 PM, Gennadiy Rozental wrote:
> Robert Ramey <ramey <at>> writes:
>> I think a better way to look at Boost is a collection of more loosely
>> coupled software components. The only coupling is to a minimal set of
>> of practices and requirements: Compatiblity with C++, Formal Review,
>> directory structure, and documentation requirements. In this view,
>> there is no place for requiring a specific library for testing,
>> requiring that some particular version of C++ not be supported.
> For this we need a process of independent boost.XXX library version-ing and
> release procedures/schedule.

It's a question of degree. Libraries can be more or less tightly
coupled. I one's library development depends heavily on Boost.Test it's
coupled to Boost.Test. Otherwise it's not. I would argue that less
coupling is better than more coupling and I think the structure
of Boost encourages that.

>> c) I have my whole boost development tree to set to master branch so I'm
>> testing against the next release. Only the serialization submodule is
>> set to develop (or a feature branch).
> Unfortunately this is not the way test runners operate

LOL - That's my point exactly. And it is one of the sources of these
problems. If things were run the way I suggest, you could make a
temporary mistake in development of Boost.Test which wouldn't ripple
though to all the libraries which use it for development testing. It
would make your life a lot easier.

>> d) Almost most all code is C++11/C++03 agnostic.
>> e) Some code is C++11+ specific. This is conditioned with BOOST_NO...
>> macros. Some tests are conditioned on these macros as well.
> In few cases this can work out like this. In many other cases maintaining
> c++03 compatibility can make library obsolete(I am not talking about my
> library). C++11/C+14 modern C++ code can and *should* look significantly
> different, with different API and implementation

It makes no economic sense to go back and re-write working code to just
because there is a new standard. There is no benefit unless one want's
to add features. Some might say that it makes maintenance easier - but
this is a decision that only a the library maintainer is qualified to make.
> This statement is conditioned on several big IFs IMO, but I am not going to
> argue.

Hmmm - there aren't any IFS here:

>> If the author of Boost.Test feels he can't support older compilers,
>> that's his decision of course.

Hmmm - I presume agree with this.

>> But he should be aware it's going to cut
>> his "market share" and encourage the usage of alternatives.

I doubt anyone would dispute this.

Robert Ramey

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