Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries

Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-14 00:39:34

On 14 May 2015 at 6:58, Vladimir Prus wrote:

> Looking at this list, I have a few questions:
> 
> - Why is that future directions of Boost must be determined by only C++ 11/14
>    libraries?

It isn't, solely. But I think that over time it will be just as the 
first libraries using partial template specialisation set the pattern 
for what followed. And the earliest libraries will, inevitably, have 
the greatest effect over subsequent libraries.

> - 5 of the libraries are not in the review queue. Why is that future direction
>    of Boost must be determined by libraries that are not actually proposed?

Also five are.

But to answer, it depends on how important you think the review queue 
is vs simply peer review. If you agree with me that it isn't a 
necessary precondition to usefulness and adoption by users, then peer 
review queue status isn't so important. It's valuable, but not a 
precondition to being "Boost ready" in the quality sense.

Peer review made more sense ten years ago when consensus was easier 
to obtain. Today's new libraries are too niche and specialist to get 
many peer reviews.

> - Many of them are marked as not supporting MSVC. Not even 2015. That sounds
>    a rather unpractical attitude, and makes me wonder, again, why would we use
>    data from these libraries to decide on any future plans?

I think most of that is a lack of realisation how complete VS2015 
support is. Some libraries really do need things VS2015 doesn't 
provide however.

I think by next year a lot more libraries will support VS2015. If 
not, then VS2016.

> > Those libraries not ported to APIBind remain in the 1.x distro, which
> > I would assume will gradually fade into obsolescence over time. This
> > makes sense, as if a maintainer is not motivated to do the port then
> > it seems proper that library should gracefully deprecate.
> >
> 
> I am not sure exactly what you mean by 'ported'. If you propose that
> maintainers need to invest time in make a perfectly working library
> be part of your "Boost 2.0", then it's a bad idea, sort of
> fire-and-motion strategy (http://www.joelonsoftware.com/articles/fog0000000339.html)

Up to the maintainer.

APIBind is merely a time saving layer which does some stuff for you. 
You can do it manually, of course, like ASIO.

> > Personally speaking, I think the new library authors are
> > overwhelmingly voting for a complete break with Boost 1.x. It makes
> > no sense to bundle these new libraries into a 1.x monolithic distro
> > when they have no dependencies on Boost.
> 
> I think this statement is unfounded. Rather, it's correct to say that
> there exist 10 libraries with "Boost" in name, hand-picked by you,
> 9 of them not official Boost libraries, and 5 of them not formally
> proposed and 3 of them not even ready source-code-wise, and:

I actually considered 15 libraries. I believe, at least from when I 
asked on boost-dev a few months ago, that this is the total.

The ones I didn't examine in detail are not too different 
incidentally. Most choose the STL11 over Boost.

> > I believe now is the time we start establishing the infrastructure to
> > shape the new Boost 2.0 distro instead of wasting resources on trying
> > to refactor the 1.x distro. APIBind is there for maintainers wanting
> > to be part of both distros. Let's make a clean break.
> 
> While the above are interesting findings, I don't think they logically
> mean that authors of these libraries are voting for your infrastructure?
> Nor does that mean other libraries should make any changes.

Again, up to each maintainer.

The authors of the libraries I reviewed appear very favourable to 
adopting APIBind as it saves them hassle, especially with supporting 
Boost.Test without the Boost.Test dependency. The Boost.Config 
emulation is handy too.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/