Niall, On 05/13/2015 07:19 PM, Niall Douglas wrote:
Tomorrow at 11am after Eric's talk I'll be presenting at C++ Now a review of the upcoming C++ 11/14 mandatory Boost libraries. I looked at fifteen libraries and decided ten were worth further investigation. I'm sure you all remember my colour coded ranking of those ten libraries by "nearness" to entering Boost:
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? - 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? - 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 sadly only have time to review four of those libraries during my talk, but one (APIBind) enables an alternative Boost 2.0 approach and I will spend 45 mins on that library alone. And here is my alternative Boost 2.0 vision:
Boost 2.0 is a alternative distro of modular standalone Boost libraries which can be each downloaded separately. Each has contemporary per commit CI testing and is nightly dashboarded by quality score by a web service under the 19 quality score headings listed at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook (still unfinished, but nearly there).
APIBind allows the library end user to dependency inject what dependencies that library uses. This allows a Boost library, in a single codebase, to be part of both the monolithic Boost 1.x distro and to be modular and standalone and part of the Boost 2.x distro. Motivated library maintainers port their Boost 1.x library to the APIBind platform, and therefore can be part of both 1.x and 2.x distros if they want.
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)
There is some empirical data supporting the inevitability of this alternative vision of Boost 2.0. Of the ten libraries I examined in any detail:
* Just 1.5 libraries have any dependencies on Boost headers at all (the 0.5 is because that library is currently removing its Boost dependencies).
* Just 3 libraries can use Boost.Test.
* Just 3 libraries use Boost Docs.
* Just 2 libraries require using Boost.Build. The rest are header only, or use cmake.
* Just 6 libraries use Travis/Appveyor for free CI testing on Linux, OS X and Windows.
* Just 3 libraries use valgrind as part of their unit testing (two are mine!).
* Just 3 libraries use coveralls for coverage reporting (two are mine!).
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: - Most are header only - Most don't depend on other Boost libraries - Many don't work on Visual Studio
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. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com