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

Subject: Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-07 05:39:52

On 6 Jun 2015 at 15:30, Edward Diener wrote:

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

Sorry. I missed that you need to explicitly opt into the switching 
functionality by using a macro which expands into the true underlying 
implementation. I thought you wouldn't need to prefix every single 
use with a macro.

APIBind does the same thing as you've done using aliasing and is 
therefore macro-free. Sadly aliasing is C++ 11 only. One could 
emulate it using shims, but they participate in overload resolution 
:(

If a library has its own namespace though (most of the newer ones 
do), a simple namespace alias can save a lot of ugly macros. You 
might add that to your docs.

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

It's more the case that right now each C++ 11 mandatory library 
simply forces on -std=c++11 in their Jamfile. That seems silly to me, 
and guaranteed to cause problems once the first C++ 11 mandatory 
library enters Boost.

What we need is something like <requirements><c++standard>2014. Or 
similar.

I agree this is a totally separate issue to your patch.

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

Did I see that you've patched all the other Boost libraries such that 
any Boost library which uses regex can be switched into std::regex?

If so, cool. But ABI worrying. If not, then it might explain me 
getting confused below (if so disregard what I say below).

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

Not entirely. What if I build my DLL A which configures Boost header 
only libraries with std and someone else builds DLL B which 
configures Boost header only libraries with boost and then a third 
party tries loading both DLLs into the same process?

On Windows it would probably somewhat work, but god help you if you 
try passing object instances from one DLL to the other.

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

Similar to APIBind's use of an ABI mangled inline namespace.

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

Apart from GCC not supporting auto-linking, great.

I really wish GCC did support auto-linking. It's a trivial feature 
add, the only hard part is getting it past the gatekeepers for the 
GCC tooling.

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

As everyone knows, my personal position on that is that we are long 
overdue a C++ 11 only separate Boost distro.

Additional distros consisting of just the well maintained libraries 
would be even better. That would reduce Boost to eighty or ninety 
libraries, and help users not constantly waste time using Boost 
libraries riddled with bugs that will never be fixed. It is deeply 
unfair that we do that to users. Undermaintained libraries should, as 
a minimum, have a big flashing warning next to their name with a 
suggestion that if you would like to take over maintaining that 
library we can do you a deal (as per the new policy agreed at C++ 
Now).

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/