Boost logo

Boost :

Subject: Re: [boost] Boost.test failures in develop
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-10-04 13:37:38

On 10/4/15 1:10 AM, Gennadiy Rozental wrote:
> Tom Kent <lists <at>> writes:
>> Unfortunately I know lots of places that are still using msvc-8.0, so I
>> don't see that full move happening any time soon
> Why would we want to wait for some places using 12 year old compiler? More
> importantly who is going to maintain the code for it? If they want to stick
> with older compiler, they can stick with older boost release.

I think this betrays a difference in what Boost or what Boost should be.

To some, it seems that "The Boost Libraries" is sort of like a product
like windows, or Clang or whatever - a large piece of code with lots of
facets which is accepted/rejected as a whole. This is what most of us
deal with in our day jobs so it seems natural to look at Boost this way.
This view leads to coupling among libraries, requirements for
coordination on testing policies, and things like that.

I don't think this is a good think

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.

I have no problems with the current setup as regards the serialization
library - a library which has more stringent requirements than most in
the support of older code, platforms and data sets.

I use

a) Xcode/CLang with C++11 enabled for development as it's very
convenient for this.

b) I use my own version lightweight test as it's enough for my needs and
I've found it simpler and more stable than other systems. I haven't
changed any code in it for ten years!. A big problem in using boost
test on the test matrix is that one is testing my development code with
boost test development code so when the later has some issue, it spills
over into my domain - and I already have my hands full.

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).

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.

f) After I get clean results with Xcode/CLang C++11 I test with GCC with
C++03 selected. Tweak the library to address any test failures
then upload to development branch of the repository.

This is a simple effective system which has worked well for me and I
believe for the wide variety of users of the serialization libraries. It
is not particularly difficult or time consuming to maintain - given the
size and complexity of the library itself.

Notice that it does NOT result in maintaining two versions of the
library. A very small portion of the code is conditional.

I don't think can or should try to impose requirements/prohibitions on
supporting old libraries from the top down. It isn't a requirement, but
it it can't be prohibited either.

If the author of Boost.Test feels he can't support older compilers,
that's his decision of course. But he should be aware it's going to cut
his "market share" and encourage the usage of alternatives.

Robert Ramey

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