
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 ecosystem.
I haven't read all the posts on this thread - but I'll add a couple observations anyway. 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 above. 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. Robert Ramey