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

Subject: Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-05 17:05:08

On 6/5/2015 3:37 PM, Andrey Semashev wrote:
> 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.

You are correct. But what are the issues about linking to a Boost 
library which needs to be addressed as you see it ?

Notice that anything necessary to linking to a Boost library can be 
figured out macro-wise for a given library by first currently testing 
BOOST_CPP_HAS_XXX for 0 to determine that it is the Boost library which 
will be used. Of course some other BOOST_CPP_XXX macro would need to be 
added to specify whether the Boost library needs to be linked or not. So 
if there is anything which could be automated as part of the source code 
to automate linking I should be able to  automatically configure it 
using macros also. As an expansion of the basic set of macros which are 
offered for each library, if the solution to linking is a generic 
solution I do not mind adding it in. But let's first identify the 
problem before we can identify any possible generic solution.

>
> 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.

Its no different from some Boost library using the C++ standard version 
of, let's say, std::function because it is available and another library 
using boost::function. Is API/ABI compatibility affected ? If so that 
has to be taken into account if you use those libraries internally. 
Suppose library X is compiled using C++11 mode and your own library Y, 
which uses library X as a dependency, is compiled without C++11 mode. 
Again those factors of interoperability between the libraries must be 
taken into account. Using my macros is not going to change any of that, 
and my macro system cannot solve that problem, or make it more or less 
than if the macro system I propose were not used at all.

So while I understand your worries I think it is a general one as more 
Boost libraries use C++ standard equivalents of Boost libraries as 
dependencies while other current Boost libraries stay with their Boost 
library equivalents as dependencies. My macro system, while making it 
easier to generically use one or the other, just brings out a problem 
that would have happened anyway. The only way to stop this problem is to 
establish rigid rules of what each Boost library must use, and we can't 
of course do that.

>
>> 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.

OK, I will look into this. If any of them  are in different headers 
and/or namespaces than 'thread' they will need there own set of HDR, NS, 
and HAS macros and initial boost/config/cpp/xxx.hpp header file to be 
included. Thanks for pointing these other implementations out ! I 
expected I might have missed a few.