Re: [boost] [c++11]

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
> standard?
>
> 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++ 
standard,
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 
of C++
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 
acceptance
of MPL upon which it heavily depends.

b) The library is written, reviewed and accepted.  As part of this process 
it
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 
remains
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 
compatibility
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 
update a
library solely for the purpose of being compatible with the later standard. 
This
would only occur if it enhance the library in some way and someone is 
sufficiently
interested to undertake the effort at enhancement.

So we have a wide array compatibiliy among boost libraries reflecting the 
point in
time when they were developed.

I expect this pattern to continue.  I don't think it's a problem. This is 
because
C++ evolution has been in general ,backward compatible, moved to more 
correct
compilers and standard libraries.

The only thing we need is to keep Boost Config going so that it can expose 
all
the features that are supported/not supported by the current crop of 
compilers.
This will be more challanging in the future as it seems that Microsoft will 
be
releasing compilers more frequently and each version will have an 
incrementally
improved feature set.

Robert Ramey