Re: [boost] Curiousity question

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.

Niall

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