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-06 15:30:54

On 6/6/2015 12:14 PM, Niall Douglas wrote:
> On 5 Jun 2015 at 5:30, Edward Diener wrote:
>
>> 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.
>
> Firstly, this is a long overdue patch and I find it a hugely welcome
> development. Thank you Edward for taking the time to implement it.
>
>> 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 didn't see system_error?+

I will look into it. Thanks !

>
>> 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.
>
> Here's a crazy idea: If Boost.Build is in >= C++ 11 build mode, turn
> all these macros on by default. That should ease testing enormously.

I am not sure what you mean by "turn all these macros on by default."

If Boost Build is in C++11 mode then the underlying Boost.config macros, 
upon which each XXX library macro is based, will no doubt show that the 
C++11 library is available for use. This in turn means that if a 
particular boost/config/cpp/XXX.hpp header is included by the end-user 
the corresponding BOOST_CPP_HAS_XXX macro will be 1 and not 0. Of course 
it is barely possible that c++11 mode for a particular compiler/version 
implementation does not support a mandated C++11 library, but that is 
not anything Boost or my XXX library macro can do anything about. But at 
least that fact will be totally consistent for all modules built with 
that particcular compiler/version implementation.

So in effect in C++11 mode for a compiler/version implementation all of 
the corresponding BOOST_CPP_HAS_XXX macros for each XXX library should 
automatically be 1.

>
> Build needs to gain an official C++ 11 build mode first though.
> Something where libraries in their Jamfile can say "I can only
> compile with C++11 or better, so if not >= C++ 11 then ignore this
> library during build".

You can do that with my macros, for any one of the libraries supported, 
by simply issuing a preprocessor #error. I show this in the 
documentation. Essentially if a library needs C++11 mode to be built 
because it requires a particular C++11 library equivalent to be used 
instead of the Boost library it can create code for the equivalent 
library XXX of:

#include <boost/config/cpp/XXX.hpp>
#if !BOOST_CPP_HAS_XXX
#error Standard Library XXX is needed to use this library.
#endif

But my macros do not have, nor are they intended to have, the general 
ability to just say that if C++11 mode is not being used it should be an 
error.

The macros are generally intended to be used by a library or code which 
wants to work in a dual mode, both pre-C++11 and C++11 on up. This is 
very different from your perspective that a libraries should be built 
that will work only for C++11. I am not in disagreement with your point 
of view if that is what a library needs to implement its functionality. 
But I believe that there are still many programmers who will design 
their library to work with either C++03 and C++11 and the macros Im have 
created offer a way of doing that when using other Boost libraries or 
their equivalent in C++11.

>
>> 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.
>
> I think this support is a great first step to making Boost less
> obsolete in a C++ 11 world. It doesn't solve all the other problems
> Boost has, but it's still a huge improvement.

Thanks ! It has very practical use for me in a library on which I am 
working, which will be a header-only template library.

>
>> Questions, concerns etc are welcome.
>
> My only real worry is the ABI problems. You need to permute the
> symbols being linked to avoid config mismatches colliding in an
> unhelpful way.

The issue as far as ABI comes down to the ability of using such a 
dual-mode library that is a built library and is not a header only library.

My point of view is that Boost needs to establish a way so that a 
library built in C++03 mode could be named slightly differently from the 
same library built in C++11 mode. We already have a system in place 
which can name a library differently depending on whether it uses the 
dynamic or static RTL of its implementation, or whether the library 
itself is a static lib or a shared lib, among other naming conventions. 
What I am positing for a built library is that the developer of that 
library should have the ability to specify that his library have a 
different name depending on whether it is C++03 or C++11 mode, and that 
this choice should work so that the correct name is used during both a 
link of the library and when that library is being used by another library.

Boost.config already has a system of auto-linking which must be 
coordinated with Boost Build to use the correct library name, so adding 
the compile-time ability to change the name slightly between a C++03 
mode build and a C++11 mode build must also I believe be co-ordinated 
with Boost Build.

>
> Perhaps for each config macro have during build the library output an
> extern dll visible empty function with a mangled name representing
> the config. On use, import and use that function. This should
> generate link errors if one is trying to use a config against a
> binary not built the same way.

This elaboration does not seem necessary to me, but I don't really 
understand its reason.

I believe the problem can be solved by a library naming convention that 
can give a C++03 library a slightly different name than a C++11 library, 
but only if the library developer needs to do this.

The use case I see for this need can be illustrated in this way. One 
creates a built dual-mode library using my macros, and the interface to 
my library specifies that, let's say, in C++03 mode you pass a 
boost::ratio object to some exported function while in C++11 mode you 
pass its C++ standard equivalent std::ratio object to some function. A 
user of my library compiling in C++03 mode will link to the version name 
of my library built in C++03 mode, and using my macros will 
automatically be passing the correct ratio object to my library's 
functionality. Likewise a user of my library compiling in C++11 mode 
will link to my library built in C++11 mode, and once again using my 
macros will automatically be passing the correct ratio object to my 
library's functionality. As long as the correct name of my library is 
being linked the ABI problem of using the correct library is solved. So 
the only ABI problem I see here is establishing a convention and a 
system in Boost by which a dual-mode library using one or more of my set 
of XXX macros might want to be built using slightly different names for 
C++03 and C++11 mode.

You may know of ABI problems between a library built for C++03 or C++11 
which are outside the problem I have tried to solve with my macro 
system. But my macros themselves are only meant to solve a particular 
problem and not the perhaps larger one of ABI compatibility between a 
library built in one C++ mode or another or possibly both.

It is important that Boost not consign its libraries to support only one 
particular subset of Boost libraries and/or C++11 equivalent libraries. 
This will prevent Boost library development from moving into the C+11 
world of programming when the idioms and libraries of C++11 prove highly 
useful to C++ library design and development. My macro system is an 
effort to support both C++ modes with the least amount of syntactical 
problems. I have no doubt as more and more compilers support C++11 more 
thoroughly that new Boost libraries will use C++11 features to enhance 
their ability. But the reality is currently such that until a full 
transition is made by all major compilers to support C++11, C++14, and 
beyond ( C++17 ? ) library developers may still target new libraries to 
accomodate the C++03 standard as the lowest common denominator, so to 
speak, of C++ compatibility.