Boost logo

Boost :

Subject: Re: [boost] [c++11]
From: Phil Richards (news_at_[hidden])
Date: 2013-06-14 06:40:35

On 14/06/2013 10:45, Robert Jones wrote:
> On 14 June 2013 10:35, Sid Sacek <ssacek_at_[hidden]> wrote:
>> With all of the cool new language features of C++11, am I correct
>> in assuming that boost library developers have no real opportunity
>> to use any of it in order to be backwards compliant with all the
>> older standard?
>> I realize there are many boost equivalents already in place, but
>> when would it become permissible to use native C++11 syntax?
> Off the cuff I believe there's already plenty of native C++11 in
> Boost, but under #ifdef control with as much alternative backward
> support as possible. The discussion points are usually around how
> much and how best to provide backward compatibility and how much is
> possible and practical.

I've sometimes pondered whether C++11 is the obvious point at which
Boost 2.x should start. And I think that the imminent move to Git may
make this a feasible idea... Or maybe I'm just being an idiot, I don't know.

Would it be possible to maintain a "boost1-mainline" (old c++, optional
c++11) and "boost2-mainline" (c++11, optional old c++) for each of the

Obviously, for those modules that are compatible with both, the two
branches would permanently be in sync, but for other modules, the
"boost2-mainline" could (at the maintainers discretion) remove much of
the conditional compilation stuff, and also take advantage of C++11
features without having to worry about old compilers.

New features could be added to just the "boost2-mainline" without fear
that they will break (or need workarounds) for pre-C++11 compilers. A
maintainer *could* decide that all future work would only be ported to
the boost2, but the boost1 packaged releases would allow users of older
compilers to keep up-to-date with modules that are being kept in sync,
and bug fixes could still be applied.

In terms of testing: well, a compiler would (generally) fall into either
the boost1 or boost2 camp, so it shouldn't increase the testing
overheads above what they already are. I suppose there might be a desire
to test some of the more popular C++11 compilers against boost1 as well
as boost2, but I'm not sure how common that would be.

The biggest downside, and the one that I think is probably the reason
why this can't/won't happen, is that potentially this ends up
significantly increasing the release managers work load by having to
handle two releases instead of one. (And having been somebody who has
done that role in my day job, I do *not* underestimate the effort involved.)

And, of course, there is the risk of patches not being applied to both
(as is already occasionally seen with the current trunk versus release

I would suspect that at some point (as compiler support improves/old
compilers disappear), maintainers would end up just working on the
boost2 mainline, and the frequency of boost1 releases would reduce

I realise it is very easy to come up with ideas that require other
people to do more work. These are just random thoughts, and I'm sure
other people have better ones. I suppose my questions are:
* Is doing this technically feasible?
* Is doing this actually desirable?
* Is doing this beneficial to the maintainers and/or the community?
* If yes to all (most of?) those: is it practical to do (in terms of
release manager load/testing etc), and if not, what could be done
(scripts, tools) to make it practical?

Sorry for being waffly, and sorry if these ideas have been proposed
before and rejected!


Phil Richards, <news_at_[hidden]>

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