Re: [boost] List of C++ 11 only Boost libraries and their status?

Subject: Re: [boost] List of C++ 11 only Boost libraries and their status?
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-11-28 14:15:22

Vicente Botet wrote
>> a) The C++ world needs many more good libraries
> 
> Agreed. I would like so see something like your incubator as a repertory 
> of independent C++ libraries. One thing we need are versioned libraries 
> with its explicit dependencies. The other is a way to install them on 
> the user work space.

Agree on all points.

Note that the incubator includes information for each library such
as first order dependencies and library version #.   Currently these
are only "documentation" and not enforced in by me or in code.
But if the incubator is successful, I would hope to see it evolve
to use these fields in a more formal way.  

In boost we are currently having working on (and having difficulty with)
dependency managment.  We don't yet have any formal requirements
for library versions (vs boost versions) - but I think we will have to
move there eventually.  I see this as another step in boost modularization.

> b) Adding many more libraries to the standard is not sustainable

> Why do you think this? The standard committee is asking permanently for 
> more contributors, more libraries. There is so much to add. This doesn't 
> mean that this doesn't takes time.

I'm just looking at the numbers.  I'm hypothesizing 500 libraries.  I 
just picked the number 500 out of thin air.  The point is that it's a 
number that I don't think the current standards process can handle
and I think that it's a number that compiler vendors cannot be 
expected to deliver.  If 500 libraries are added to the standard, then
no vendor wil deliver the whole thing.  Then what does it mean to
be part of the standard? 
 
> c) Therefore, the role of boost should shift away to making libraries
> for the standard toward making good C++ libraries in general.

> I would like to see more Boost libraries proposed for the standard. Your 
> Serialization library would surely have a good feedback, once it is 
> adapted to C++14.
> 
> I would like to see a Boost C++14 libraries with much of the current 
> Boost libraries ported to C++14, removing all adherences to old 
> compilers. Only in this case we can pretend yet that Boost could be a 
> trampoline to concrete standard proposal. C++14 and C++98 are so
> different.

Agreed - but these tasks entail a huge amount of work - who is going 
to pay for this? Re-defining serialization for C++14, making a compliant
implementation for review, writing the standardese, and having
compiler vendors code up their own versions would  be a huge
amount of work - and who pays for this?  And what value is in it?
What would it add that we don't already have.

I confess that I've never been sold on the concept of a standard
library implementation - at least to the extent that it has grown to.
I've questioned my convictions when someone pointed out to me 
that boost was embraced by many institutions only when parts of
it got added to the standard library.  This made it possible to use
without getting blamed when something problematic came up.

> This C++14 library should be modular and the user should be able to 
> install each library independently.

YES! YES! ...

BUT - this is not quite so simple as it may appear.   I've become 
skeptical of ambitious efforts such as rypll and others.  On the 
other hand, I'm seeing that git hub is being used to good advantage
by users of the incubator.  At least I haven't had complaints 
from users that they can't download and test any of the libraries
there.  I'm thinking that things evolve where the modular
boost directory structure becomes sort of "standard" any
other libraries can be just cloned and a simple "b2 headers"
can be run (maybe not even that).

And there is the dependency issue again.  

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/List-of-C-11-only-Boost-libraries-and-their-status-tp4669425p4669597.html
Sent from the Boost - Dev mailing list archive at Nabble.com.