Niall, On 05/14/2015 07:39 AM, Niall Douglas wrote:
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.
My point is that it's strange to shape Boost to accommodate libraries not actually proposed to be part of Boost. It's fairly speculative approach. And I don't see usefulness and adoption by users in your table either.
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.
Well, other parts of your post suggest that perfectly useful libraries will be 'deprecated' or something unless they are somehow migrated to this new world. Did I misunderstand?
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 assume you mean "standard library of C++ 11"? STL is a very specific part of it.
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.
That might be good, but it does not explain how this tables supports your proposal for Boost 2.0? You've hand-picked a few libraries, ignoring half of libraries in review queue and created a table that shows no real convergence on anything. It hardly supports your proposal. Now, the proposal *might* be good, it's just your statistics seems not a good argument for it. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com