Re: [boost] [c++11]

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 
sub-modules?

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

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

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
-- 
Phil Richards, <news_at_[hidden]>