Subject: Re: [boost] Curiousity question
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-13 13:46:14
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:
>>> 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
> 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.
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk