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 <ssacek@securewatch24.com> 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, <news@derived-software.ltd.uk>