Boost logo

Boost :

Subject: Re: [boost] Curiousity question
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-13 12:18:00


On 10/13/2016 11:17 AM, Sylvester-Bradley, Gareth wrote:
> On 13 October 2016 15:33, Edward Diener wrote:
>> I understand that and I think that is the general consensus. But what might happen,
>> not that it seems to bother anyone much but me <g>, is that your library, which supports
>> C++03, is nevertheless "compiled" by some programmer(s) using C++11 in their own
>> project. Then their normal use of std::shared_ptr ( because it's there and naturally
>> supported by their compiler implementation in C++11 mode ) doesn't really "play well"
>> with your own use of boost::shared_ptr. Of course you may well say "what's the big deal,
>> when you interface with my library you will use boost::shared_ptr and have a
>> dependency on it, while otherwise you have chosen to use std::shared_ptr and have a
>> dependency on your compiler's implementation. I see no problem with that." And
>> technically you would be right, but practically the user of your library might feel differently about it.
>
> I think you've summarised nicely how I feel about it - our need to support C++03 users while not making C++11 users uncomfortable.
>
> 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. 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.

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.

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.

>
> #ifndef BST_XXX_HPP
> #define BST_XXX_HPP
> #ifndef BST_XXX_BOOST
> #include <xxx>
> namespace bst
> {
> using std::xxx1;
> using std::xxx2;
> }
> #else
> namespace bst
> #include <boost/xxx/xxx1.hpp>
> #include <boost/xxx/xxx2.hpp>
> namespace bst
> {
> using boost::xxx1;
> using boost::xxx2;
> }
> #endif
> #endif
>
>
> Cheers,
> Gareth


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk