On 10/13/2016 12:50 PM, Sylvester-Bradley, Gareth wrote:
On 13 October 2016 17:18, Edward Diener wrote:
On 10/13/2016 11:17 AM, Sylvester-Bradley, Gareth wrote: <snip>
We do it using-declarations in namespace bst (I pronounce it 'best'!), in headers called "bst/xxx.hpp", which default to symbols from std, but can be instructed to use Boost. No auto-detection. There's the ABI issue that Gavin Lambert mentioned earlier. Otherwise seems to work well for us. Sometimes (like bst::placeholders), there's a tiny bit of extra work to put the Boost names in the right places, but not often. We also sometimes switch a bunch of symbols together where that makes sense (e.g. having consistent std or boost function/thread/chrono). I agree with Peter Dimov that "bst" or "cxx_dual" would seem to live best outside of the main Boost distrib though.
It seems a bit onerous for you to do what's below for each Boost versus C++ standard library you want to work with.
The namespace alias approach is simpler, obviously. But the advantage of using-declarations is we only bring in names we know are a good match, so you can't get suckered into taking advantage of something that wouldn't be available/equivalent in bst/cxxd namespace if you were building in the other mode. And like cxx_dual, we write it once and forget about it...
The using-decl approach also has the advantage that we can solve problems like the placeholders. Not sure how many of these kind of things exist but it's certainly one issue.
I have updated the documentation for CXXD to explain how you could use using-declarations with a mod's low-level implementation header to provide yourself with the greatest amount of flexibility. You can view this at http://eldiener.github.io/cxx_dual/doc/html/cxxd/sadvanced.html#cxxd.sadvanc....
Your test has "using namespace cxxd_bind_ns::placeholders;" (https://github.com/eldiener/cxx_dual/blob/master/test/test_bind.cpp#L38). If you omitted this, and changed the uses of _1, _2, to cxxd_bind_ns::placeholders::_1, cxxd_bind_ns::placeholders::_2, I think you'd discover you've not mapped the Boost placeholders.
As I originally replied I did not map the placeholders nested namespace for the bind dual library. But you are wrong in your assumption above. CXXD works perfectly well with the cxxd_bind_ns::placeholders::_n notation. There is no problem in C++ using a nested namespace for a namespace alias that is set to the namespace in which the nested namespace resides.
I also don't see below how you decide to define BST_XXX_BOOST or not for some XXX library, though I assume you have some mechanism, whether automatic or manual, that makes that decision.
No auto-detection. Default to std, manual decision to define BST_XXX_BOOST per-project/platform.
As far as cxx_dual it really only depends on Boost Config for its automated decision-making ability. I am not keen on duplicating the Boost Config functionality which cxx_dual uses, although I will look into whether or not it could be done easily enough. I tend to doubt it.
Agreed.
The cxx_dual support macros for naming a non header-only library and testing for valid variants for a library do use Boost PP and Boost VMD. And of course the tests use other Boost libraries extensively, including of course lightweight test.
(I also have a set of BST_TEST_XXX macros that map to Boost.Test or Google Test or Catch... but that's another e-mail thread!)
Peter's objection to cxx_dual is well-founded, but I can't help thinking that the issue is not so much the Boost monolithic distribution actually existing on disk, but that using a Boost library creates at the very minimum header file dependencies at compile time and at the maximum dependencies on shared or static libs at run-time.
Basically agreed, but for C++11 users of our library, who only want to use bst/cxxd in std-mode, why should they have to have a Boost install at all?
As I originally replied if you know exactly for what compiler implementation and in what C++ mode your code is going to be used you certainly can hard-code the choice of whether you are going to be using the Boost version or the C++ standard version of a particular library. And naturally if you know you will always be using C++11 you don't need the Boost version of a library if the C++ standard version is fully adequate for what you want. What I gathered from my original OP from everyone's response is that either: 1) Programmers would rather hard-code a choice of using a Boost library or its C++ standard library equivalent in their code based on whether their code was meant to be used for C++11 or above or not or 2) Roll their own hand-made system for choosing based on their individual needs rather than use a library like cxx_dual which automatically makes the choice of whether to use a Boost library or its C++ standard equivalent based on what is available at compile time. I do appreciate very much everyone who answered my query.