Re: [boost] List of C++ 11 only Boost libraries and their status?

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/