Boost logo

Boost :

Subject: Re: [boost] Curiousity question
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-10-13 07:34:23

On 12 Oct 2016 at 22:04, Edward Diener wrote:

> > Haven't quite gone that far yet myself though, though I know that your
> > cxx_dual library and Niall's similar library are along those lines.
> The impetus for cxx_dual is that I was ( and still am ) working on a
> library where shared pointers and function callables are part of some
> public interfaces. So I was trying to decide, do I use boost::shared_ptr
> or std::shared_ptr, do I use boost::function or std::function ? And I
> had some answers, but whatever it was I felt I was sure to run into a
> potential end-user of my library who would feel, based on his compiler
> implementation, compiler support for C++11, compiler options, OS for
> which he was using my library, that whatever I chose would be wrong for
> him. Of course like most programmers I could simply say, these are my
> choices and if they don't correspond to what you are otherwise using if
> you use my library, it is up to you to adjust. My OP is an effort to see
> how other programmers involved with Boost think about this.

Firstly Edward, you've done a really nice job with cxx_dual. Far more
polished than my effort, which I effectively stopped work upon after
it was clear after my C++ Now 2015 presentation of it showed there
was little interest in such a facility from Boost people.

I also am finding these responses very interesting, and thank you for
asking the question, indeed you preempted me asking the same
question. The responses confirmed my increasing suspicion that people
are either rolling their own on the spot or else just assuming C++
11. Not enough people want a formal framework for switching between
STL 11 implementations.

BindLib is now Boost-lite, and instead of focusing effort on
providing code to shim between standards implementations I am now
focusing effort on a new collection of standards aspiring C++
libraries based on the feedback yielded from the informal meetings I
ran during CppCon 2016 (and which were minuted, and those minutes
were distributed to those who attended). The new collection obviously
includes all my own libraries, but I wouldn't recommend anyone else
use it yet, it's too rough because it's using bleeding edge cmake and
other tooling (e.g. it needs trunk LLVM 4.0) as well as bleeding edge
C++ 17. I'm hoping to add a year of maturity to it first, and then
open it up to anyone else who wants to add their libraries.

I should emphasise that Boost lite is not an alternative to Boost,
more a staging ground for new libraries. A library should be able to
coexist in both collections, and my aim is that Boost lite's many
perhaps too bleeding edge facilities will greatly ease initial new
C++ library development as a half way house to entering the Boost
review queue and later entry into Boost. The idea is that the new
tooling can automate a great deal of development tedium away, but the
swap is that the C++ library has extremely strict requirements placed
on exactly how it's organised and laid out to the extent that you'd
have a lot of refactoring needed to bring in an existing library.


ned Productions Limited Consulting

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