Boost logo

Boost :

Subject: Re: [boost] Curiousity question
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-29 14:34:36

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

> Your test has "using namespace cxxd_bind_ns::placeholders;" (
> 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


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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at