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...
OK. But I don't know think that "suckered into taking advantage of something that wouldn't be available/equivalent" is much of a problem. Of course there may be differences between a Boost library and its C++ standard equivalent, but a programmer needs to understand what he is doing anyway when he programs a library and if he doesn't he shouldn't be tempted to use functionality which he does not understand completely. In cxx_dual you can also use using-declarations, rather than the automatic namespace alias, by using the low-level mod implementation header, but admittedly I do not explain how to do this and I appreciate that you have brought this up. I will add it to my documentation for cxx_dual.
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. 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.
I agree that I did not map the placeholders for bind. I thought mapping the namespace was good enough. In general I fought against more than one namespace alias per mod in cxx_dual ( and correspondingly against more than one namespace macro per mod at the low-level ).
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.
Doing it manually is fine but I think automatic should always be there for ease of use. Cxx_dual does automatic detection but then allows manual override macros to change it.
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!)
And I was raked over the coals for using macros <g> ! I am glad others are, like me, not afraid to use them.
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?
Point taken. I am considering a stand-alone cxx_dual, but its reliance on Boost Config is a pretty big burden to overcome unless I incorporate much Boost Config logic in my own code, which I am not sanguine about doing. Boost Config is a magnificent achievement, without which cxx_dual does not exist. I acknowkledge that in the doc.
<snip>
Cheers, Gareth