Subject: Re: [boost] [1.51][Release] Short release cycle
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-07-03 12:49:46
Lars Viklund wrote:
> On Tue, Jul 03, 2012 at 11:05:10AM +0000, Stewart, Robert wrote:
>> Steve Ramsey wrote:
>> Right. Boost is much less about long term support than it is about
>> advancing the state of the art in C++ library design and
>> standardization. Accommodating users of older compilers has always
>> been up to the individual library author. Conditional compilation is
>> a pain they must choose to incur and endure. If you want a library
>> to add support for your platform, it's up to you to encourage the
>> library maintainer to add support or to contribute patches in the
>> hopes the maintainer will adopt them. There is no other option.
> Fair enough, it seems like I've misunderstood some aspects of our
> mission. I've always thought it was to smooth out the fragmented
I haven't read all the posts on this thread - but I'll add a couple
a) I don't see any real conflict between these points of view.
b) This is a variation on a problem boost has successfully
dealt with for years.
Three is a wide variety of C++ compilers which boost supports.
Most of these fail in some way to be exactly standard conforming.
In some cases, there are very few failures and in other cases
there are many. This has been handled by boost.config in a
very systematic, convenient and complete way by defiining
macros which indicate the failures, non-supported features etc
of the particular compiler. see for example BOOST_NO_0X_HDR_ARRAY etc.
Boost has never required that a library support a non
conforming compiler - only that it be compatible with the C++
standard. Never the less, authors who want to see their
library used have used the above system to make their library
as widely useful as is practical.
That is, a library author may
a) use C++03 (or decline to re-implement an existing library using C++11)
b) selectivly use C++11 features and support both via the macros
c) require C++11 features - and gracefully fail to compile when
the macros above indicate that the compiler can't be supported.
The size and nature of the library itself will likely determine which
of the above will be the best course.
It's not so much that I'm advocating any thing in the above list. It's more
that I believe that this will happen and that it's a good solution.
Perhaps the only thing I would add is that library documentation
and website library list might add a little data as to what level of
C++ compliance the library requires.