Re: [boost] Update on status of C++ 11 only Boost fork/modular distro

Subject: Re: [boost] Update on status of C++ 11 only Boost fork/modular distro
From: Mikael Persson (mikael.s.persson_at_[hidden])
Date: 2014-10-07 16:55:59

Personally, I find this proposal very scary. I'm just gonna give my opinion
on this, make what you want of it.

One little thing, I'm not sure that STL11 is a particularly good name for
this, since most of the new C++11 libraries would not be classified as
"STL" libraries (except for unordered containers and <array>). But that's
just a trivial issue of terminology.

You state in your readme for your generator:
".. or write some brittle bindings which manually replicate STL items .."
In my experience, what can make those kinds of manual bindings brittle are
all those subtle incompatibilities (often undocumented) between analogous
components of the alternative implementations. It's not hard to take a list
of standard components and turn that into a list of using statements /
typedefs / aliases within a new namespace, because such lists are not that
long in general (20 to 50 things per header, at most) and it's not hard to
do this well and to maintain them. I find that there's nothing particularly
brittle about that "human process". Replacing that process with a reg-expr
generated automatic process can only make it more brittle, with very few
benefits, and might require significant tinkering until it works reliably,
and I don't care how smart that generator is (using clang's AST lib or
not), I cannot see this becoming more reliable than a hand-written and
actively maintained equivalent. And after all that, it does not address the
main weak point of such bindings, which is, as I said, dealing with the
subtle incompatibilities and platform-specific quirks.

>From a distribution point of view, I see some big problems too. I guess the
idea, if I understand correctly, is to distribute your binding generator
along with the select-few boost header-only libraries, and then, the user
would have to run the binding generator for his particular platform to
generate the implementation-detail binding headers of those boost library
ports. Or, if you want to spare the user from having to do this, then you
must distribute a specific version of all the headers that will work for
their particular platform (OS, compiler and std-lib implementation) and the
particular versions of those platform components. Either way, this is a
distribution nightmare.

As for "forking" boost based on this, I don't understand why this is
necessary, or maybe I don't quite understand what it is meant to really
involve. Most boost libraries already contain a significant amount of
conditional code and workarounds to deal with platform-specific issues or
to use beneficial features that only some platforms support (including
C++11 features). Why would it be necessary to have a completely separate
version or distribution of those libraries that are targeted at platforms
with the (mythical) feature-complete C++11 library implementation? That is,
if you really mean to "fork" the boost libraries in that way, there is
going to be enormous costs associated to doing that, mostly in terms of
maintenance and man-power.

I think that a much better alternative strategy is to do what boost has
done with Boost.TR1. Why not create a library wrapper like Boost.TR1 but
for C++11/14? Isn't that what users want, i.e., to be able to use standard
C++11/14 library components and not have to worry about running their code
on platforms that don't support it or only partially? I mean, people who
use Boost.Thread today, instead of <thread>, use it because it works
everywhere. But if they could include something like
<boost/cpp11/thread.hpp>, and use "std::thread" and friends, then the only
remaining platform-specific work would be to install and link against
libboost_thread for platforms that do not provide the standard <thread>
library.

An additional way of doing this is to simply require that the maintainers
of the libraries that have been standardized to update their library such
that it binds to the standard C++11 library implementation (as thinly as
possible) whenever available and sufficiently compatible (I think that most
of the boost libraries are today, they seem to have recovered from all the
mayhem following the C++11 standard and all its slight differences w.r.t.
Boost). In other words, if you include <boost/thread.hpp> on a
feature-complete C++11 platform, it should do little more than include
<thread> and bind its components to the boost namespace.

In both cases, the responsibility of maintaining the C++11/14 compatibility
in those boost library rests on the shoulder of the individual maintainers.
No forks required. And the local bindings (generated or not, from boost to
std or vice versa) can be maintained more easily. Incompatibilities and
other platform-specific can be dealt with more practically by manually
maintaining the bindings. And users simply need to be advised about what
features a platform should have to allow a specific boost library to be
used standalone and / or without having to install and link to a
pre-compiled library.

Maybe I completely misunderstood your goals, and all I said are things you
had already considered. I hope so.

This is just the way I see things. Hearing the words "fork" in the same
sentence as "boost", gives me chills... (unless it means "fork" only in the
sense of a temporary developement branch that is meant to be merged back
quickly).

Mikael.