Boost logo

Boost :

Subject: Re: [boost] [c++11]
From: Asbjørn (lordcrc_at_[hidden])
Date: 2013-06-17 18:28:45

On 15.06.2013 10:10, John Maddock wrote:
>> I used to see Boost as an empowering library, enhancing and evening out
>> the playing field among the compilers out there.
>> Some seem to see it as a playground to gain recognition and fast-track
>> things into the coming standard libraries, instead of producing
>> something usable in the real world.
> Ouch. Boost has always been about championing the "next thing" and
> always been ahead of the compiler curve, if that wasn't the case we'd
> still be targetting VC6. Yesterdays bleading edge is tomorrows mainstream.

Just a few cents from a "Boost user", as a "core dev" in a small but
active open source project.

The short version: I don't mind new Boost libraries being C++11-only, if
they are clearly marked as such.

The long version:

The "bleeding edge" you talk about is why Boost is a painful dependency
to have, at least in our experience. It's monolithic structure does not
help either. That said there's a lot of really nice and useful libraries
in Boost, so we accept the pain.

Since I also work on a volunteer basis on this open source project, I
appreciate that maintaining compatibility is a difficult balancing act,
given the potentially high opportunity cost vs implementing new, useful

So, as a Boost user, what I'd like to see is a clear status for each
project, concerning

- Compiler support: I wouldn't mind C++11-only "leaf libraries" (that's
not a dependency of a non-C++11 library) if they are clearly marked as
such. Also is any effort spent on supporting a wider set of compilers
and platforms, or "just the usual suspects"? I don't have big issues
with limited compiler/platform support as long as it's not a core
library and it's clearly marked.

- Maintenance: Is the library maintained, and if so, at what level? Are
only supplied patches applied? Or is there a maintainer who will
actively try to fix bugs. IOStreams for example seems a bit lost at sea
at the moment, with issues lingering. I didn't know how bad it was until
I ran into a few serious issues after writing considerable code relying
on IOStreams some time ago. I ended up having to replace the IOStreams
code with my own.

- Inter-depdendencies: A list of which other Boost libraries a given
library depends on, so I could check the above for the dependencies.

Ideally a brief version of the first two points would be listed in the
main "Boost Libraries" overview.

With this information it would be easier to determine if a Boost library
is suitable to be used by us for our project.

Anyway just my 2 cents, and in any case thanks to all the devs here for
their great work.

- Asbjørn

Boost list run by bdawes at, gregod at, cpdaniel at, john at