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 05:30:03

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.

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.

I give a basic example how the macros are used using regex in the 
documentation.

Of course there may be differences between the C++ standard library 
equivalent of a Boost library and the Boost library itself. But for the 
most part the system I have provided will work and when it does not work 
because of differences, at the very least you can use the 
BOOST_CPP_HAS_XXX form of macro to decide what you want to do.

As to whether or not it belongs in Boost.config:

1) The macros for any given library 'XXX" are not automatically brought 
in by the normal 'include <boost/config.h>', so they affect nothing in 
Boost.config.

2) The system is based directly on Boost.config detection macros in 
order to determine whether or not a particular 'XXX' equivalent library 
exists.

3) The macros do "configure" the ability to use either a Boost library 
or its C++ standard equivalent using the same syntax.

4) The system could be put in its own library with a dependency on 
Boost.config only, but it is such a simple system already dependent on 
Boost.config that I felt it would easily fit as part of Boost.config 
than as its own separate library.

5) I wanted to push it to 'develop' and let others use it and add the 
per library PR's to test it. If it was found to be flawed or could be 
better in any way I could then change it on 'develop', and if people 
were satisfied with it as a workable solution it could eventually be 
merged to 'master'. If not it could be easily removed if necessary since 
it exists in its own header files apart from the rest of Boost.config. 
Even its documentation is a separate Boost.config .qbk file.

I know these macros work and provide an easy transition between using 
the C++ standard equivalent of a Boost library if it exists in a 
compiler implementation or the Boost version if it does not. I made no 
attempt to create a per XXX library bridge between functionality of the 
C++ standard equivalent of a Boost library and the Boost library itself 
when the functionality differs because one has functionality that the 
other does not or, in the rarer case, when the same syntactical 
functionality works differently. I feel that such an attempt at 
interoperability is outside the purpose of the system I provide. For 
many of the mainstream Boost libraries which are now in the C++11 
standard as libraries the system I have created, via macros, of 
including the correct header and use the correct namespace works largely 
flawlessly without having to consider differences. I am thinking of such 
closely equivalent and highly used libraries as 'function', 'bind', 
'ref/cref', 'regex' etc. The system I have provided is meant to make 
writing code much easier without having to worry about which library I 
am using, the C++ standard version or the Boost version.

If there are better interoperable systems I would love to hear about 
them. But for me personally any system where I have to jump through 
hoops simply to be able to write code which works whether I am using a 
Boost library or its C++ standard library equivalent, will not be worth it.

The fork of config on which this PR is based is under my own account at 
https://github.com/eldiener/config.git if anyone wants to play around 
with it. The documentation I added to the Boost.config docs explain 
everything better than I have here. I am of course willing to support 
this work. My local tests I can push to forks of each XXX Boost library 
supported by these macros, since I have already made local branches for 
each XXX library with tests added for these Boost.config macros to show 
that they work.

Questions, concerns etc are welcome.