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/