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
#include namespace bst { using boost::xxx1; using boost::xxx2; } #endif #endif Cheers, Gareth