Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.

Subject: Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-06-05 15:37:52

On Friday 05 June 2015 05:30:03 Edward Diener wrote:
> On 6/5/2015 3:41 AM, John Maddock wrote:
> > There is a pull-request for Config to provide support for switching
> > between boost:: and std:: library equivalents:
> > https://github.com/boostorg/config/pull/63
> > 
> > My questions are:
> > 
> > * Is this the right approach?  And,
> > * Is Boost.Config the right place for it?
> > 
> > Thanks for your comments, John.
> 
> That is my pull request so I will comment now that you have so
> graciously provided a forum for my idea.
> 
> I don't know what "the right approach" would be but this is one approach
> that does work easily, following the documentation I have written about
> it and added to the Boost.config documentation.
> 
> I have written and added tests for all the Boost libraries involved
> which have a C++ standard version which may be interoperably used
> instead of the Boost version in code. These tests I would add as PRs to
> the particular libraries once this config PR is pushed to 'develop'. The
> tests are largely proof of concept tests that show that code does work.
> The tests are not meant to be extensive tests for each library's
> functionality.
>
> I have also used the code successfully in this PR for a library I am
> developing.
> 
> It is very easy to use. For library 'XXX':
> 
> 1) Just include the particular Boost.config header provided for a
> particular interoperable library XXX:
> 
> #include <boost/config/cpp/XXX.hpp>
> 
> 2) Include that library's main header file using the macro provided for
> that library:
> 
> #include BOOST_CPP_XXX_HDR
> 
> 3) In code for that library's functionality use the namespace macro
> provided for accessing the library's functionality:
> 
> BOOST_CPP_XXX_NS::some_functionality etc.

In general, this might be useful in some constrained contexts, but I have a 
few concerns:

1. What if the Boost version requires linking with a built library? These 
headers won't be able to hide that.

2. I'm worried if these tools will be used in Boost libraries in a way that 
affects library API/ABI. What if one library uses these tools and the other 
doesn't - will these libraries be able to interoperate? Or is it a user's 
problem? There is also the possibility that Boost is built in C++03 mode and 
the user builds his code in C++11. I think this will be most apparent with 
utilities like shared_ptr and function, which are often present in the 
interfaces.

> If you need to do anything different depending on whether you are using
> the C++ standard version of the library or the Boost version of the
> library you can test the BOOST_CPP_HAS_XXX macro, which is 1 for the C++
> standard version existing in the compiler implementation and is 0 for
> only the Boost version existing in the compiler implementation.
> 
> That's it for any given library supported. You are using the C++
> standard version of the library if it exists in the compiler
> implementation or the Boost version of the library if it does not exists
> in the compiler implementation.
> 
> The Boost implementations supported are:
> 
> array
> atomic
> bind
> chrono
> function
> hash
> mem_fn
> random
> ratio
> reg/creg
> regex
> shared_ptr
> thread
> tuple
> type_index
> type_traits
> unordered_map
> unordered_multimap
> unordered_set
> unordered_multiset
> 
> If I have missed any Boost libraries which have a close C++ standard
> equivalent just tell me and I will add it with some added tests for that
> particular library.

If you have thread you could also add mutex, condition_variable and locks.