On 8 May 2014 at 9:44, Glen Fernandes wrote:
I think Boost needs forking into a C++ 14 only edition and a C++ 03 compatible edition, with the C++ 14 only edition exclusively based on the C++ 14 STL where possible (and not Boost). I also think we need a three stage peer review process instead of the present single stage. I also think we need much tougher requirements for entry into Boost.
I'd be worried that this would inhibit improvements to C++14 components that have a Boost equivalent. Consider if this approach was taken with C++11, and we had a Boost version that used C++11 components, like std::shared_ptr, where possible. Two of the improvements we have for fundamentals TS1 and TS2 are based on features that we added to boost::shared_ptr, boost::make_shared, boost::allocate_shared (Peter's change to std::shared_ptr - http://isocpp.org/files/papers/N3920.html - and my forms of std::make_shared and std::allocate_shared - http://isocpp.org/files/papers/N3939.html).
I would imagine a C++14 only Boost would reimplement parts of the C++ 14 STL which need it badly enough, especially if to be proposed as a replacement. For example, std::valarray<T> was totally replaced with an alternative. There are many other examples.
Then there is the matter of broken vendor implementations. VC10, VC11, VC12 all have broken (or suboptimal) implementations of many C++ standard library functions.
As does libstdc++. I'm thinking especially of std::regex which only was finished very recently.
Not everyone upgrades to the latest versions of those compilers, either.
C++ 14 only Boost would be like Boost of the 1990s, highly demanding on compilers and only guaranteed to work on the latest major revision. The idea would be to regenerate that excitement of the bleeding edge, get people enthusiastic with the possibilities again.
I worked at Microsoft until February 2014, and even as late as 2014, there were teams in certain parts (OSD, ASG) that were using VC10 and VC11 (and one that still cared about Boost 1.41). It makes sense to have Boost equivalents that are non-broken, better implemented, etc.
And for which the compatibility Boost would remain: a very high quality emulation of the C++ 11/14 STL in C++ 03, something which is very valuable to a lot of rich corporations. Me personally, I'd delay open source release by 12 months unless clients pony up a (small) subscription to fund contractors to work on bug fixes and maintenance, as getting people to do that for free is becoming increasingly hard. An alternative is a formal bounty system, with bounty credits earned per unit of monthly subscription. My concern is that we are putting off the C++ 14 fork of Boost until "the time is right". If you look at monthly commits, active contributors, mailing list posts esp. to boost-users, all have dropped dramatically since 2011 and are trending downwards. On some measures Boost is approaching one third of the activity it used to be. It is quite frankly scary. I can supply graphs if you'd like? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/