Boost logo

Boost :

Subject: Re: [boost] List of C++ 11 only Boost libraries and their status?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-11-25 07:06:16

On 24 Nov 2014 at 22:05, Pete Bartlett wrote:

> I'd want to give authors a free hand, as much as possible. E.g. if a new
> library came along that needed a tuple facility, they should feel free to
> just use <tuple> / std::tuple rather than being obliged to template on tuple
> type (or more sophisticatedly, use the Boost.BindLib library that Niall says
> is around the corner), just in case someone is stuck with boost::tuple. If
> someone else is stranded on VS2005 (or whatever) and comes along with a
> patch to backport support to boost::tuple, then great.

Be aware that for the switchable underlying STL facility, BindLib
absolutely requires template aliasing support in the compiler
(otherwise he can't generate the binds from your library to either
boost::tuple or std::tuple). And template aliasing is a C++ 11
feature, so your compiler needs to be C++ 11 mode.

tuple, incidentally, is in the presupplied bindings, but I have
absolutely no idea if it works. No reason it shouldn't, though.

> For existing libraries on the other hand, it seems wrong to break
> backwards-compatibility without a really good reason so if a library is
> c++98 now, why not leave it that way. If someone thinks a particular domain
> can be done better using c++11 facilities, then I think a "v2" of the
> library makes sense.

One of BindLib's main goals is to solve the API and ABI versioning
problem in all Boost libraries. Once a library enters Boost it is
supposed to keep backwards API compatibility and optionally ABI
compatibility, and doing this usually involves an awful lot of #ifdef
which is a pain to debug and maintain.

A BindLib based library lives in some unique namespace you don't need
to care about as the binds and any inline namespace support in your
compiler make that unique namespace not appear to code using your
library. That way if I change AFIO to have a breaking API change, I
can ship v1.2 of AFIO *and* v1.3 of AFIO and both versions coexist
happily just as a Boost.Filesystem based AFIO coexists happily with a
STL Filesystem based AFIO. Code using AFIO that is tied to particular
version simply binds in a specific version of AFIO, and can carry on
with that API version as long as it feels like, though probably
without bug fixes.


ned Productions Limited Consulting

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