Subject: Re: [boost] [c++11]
From: Robert Ramey (ramey_at_[hidden])
Date: 2013-06-15 14:38:33
Sid Sacek wrote:
> This was probably discussed many times already, but I seem to not
> have been paying close enough attention.
> Maybe someone can point me to the discussions in the archives...
> 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
> I realize there are many boost equivalents already in place, but when
> would it become permissible to use native C++11 syntax?
Speaking from memory here.
There is no real boost wide policy on this. Somewhere on the boost site
it's stated that as long as the library is conformant with the current C++
compatibility with broken/out of date compilers/standard libraries
shall not be a requirement.
In practical terms - it depends a lot on the nature of a library, the state
and the views of the author. Here's a typical scenario.
a) C++ has or aquires some feature which makes it possible to make a new
library. Example, the serialization library came shortly after the
of MPL upon which it heavily depends.
b) The library is written, reviewed and accepted. As part of this process
will likely be tweaked to support the important compilers available.
c) Compilers evolve, libraries evolve and the C++ standard evolves. But the
library more or less just get's maintained to fix anything that breaks. It
backward compatible indefinitely.
d) Unless - some new feature is added at a later time. The library may not
be backward compatible any longer. Example, enhanced performance for POD
types was added to binary archives. This had the effect of breaking
with MSVC 6.0. No one complained and that was the end of it.
Basically there is no incentive nor is it cost effective to go back and
library solely for the purpose of being compatible with the later standard.
would only occur if it enhance the library in some way and someone is
interested to undertake the effort at enhancement.
So we have a wide array compatibiliy among boost libraries reflecting the
time when they were developed.
I expect this pattern to continue. I don't think it's a problem. This is
C++ evolution has been in general ,backward compatible, moved to more
compilers and standard libraries.
The only thing we need is to keep Boost Config going so that it can expose
the features that are supported/not supported by the current crop of
This will be more challanging in the future as it seems that Microsoft will
releasing compilers more frequently and each version will have an
improved feature set.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk