-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Jones Sent: Friday, June 14, 2013 5:46 AM To: boost@lists.boost.org Subject: Re: [boost] [c++11]

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

If that is what coders are doing, it sounds pretty complicated. Multiple #ifdef blocks of code that do the same thing, and combinations of code to build and test, and hope that it still all works when shipped. It could become #ifdef hell. Sounds like it's not really worth the effort and simply just stick to the old style. -Sid

On 14/06/2013 10:45, Robert Jones 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

On 14 June 2013 10:35, Sid Sacek wrote: 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,

On Friday 14 June 2013 11:40:35 Phil Richards wrote:

...

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? As a library maintainer, I wouldn't like doubling the maintenance effort and forking the code into boost 1.x and 2.x. That, of course, implies that I want to support C++03 compilers in my library (which I do, at least for a few years from now). But, I think my point is, with the combination of breaking boost into sub-modules, and using git, that, in your case, you wouldn't need to fork your code base. The boost2 release would incorporate your (single)

IMHO, it would be much better to just state clearly the level of compatibility for each library in the docs and the library list [1], so that this information is immediately apperent to users. Library authors may choose to drop support for older compilers as they see fit, in newer Boost release. I think, this will make a more natural transition to C++11. The problem with this approach is that, as an end-user, you might find

On 14/06/2013 11:53, Andrey Semashev wrote: mainline as a sub-module, as would the the boost1 release. It's only if you wanted to support both separately that it would double your maintenance effort, and that's assuming that you were trying to implement the same functionality in both. And with git's cherry-picking merges, any common code would be a lot easier to share between branches. It is more likely a maintainer would draw a line under boost1 (except bug-fixes), and do all new development on boost2. The testing system would still test boost1 on appropriate platforms, and would catch any incompatibilities that might get introduced. that Boost 1.78 supports library X for C++03 (and contains features you want), but the last version of Boost that supported library Y is 1.61. Yes, you can roll your own set of modules, but then you are at the risk of other modules being incompatible between versions. As I said, it was just a thought, Phil -- Phil Richards,