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-the... Sent from the Boost - Dev mailing list archive at Nabble.com.