Re: [boost] Anyone is interested in being review manager of ‘Application’?

Subject: Re: [boost] Anyone is interested in being review manager of ‘Application’?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-08 13:34:38

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/