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

On 6/7/2015 5:39 AM, Niall Douglas wrote:

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.

Good idea ! You could also use a using directive, with its usual pitfalls, easily enough: #include #include BOOST_CPP_XXX_HDR using namespace BOOST_CPP_XXX_NS; etc.

...

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

No, I did not do that. What I have done locally, but not yet created forks and PRs, is to add simple tests to each Boost library that show that the technique of using my macros will work whether one compiles in C++11 mode or not.

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.

This is no different from anyone doing this manually without the use of my macros. Any DLL can pick which libraries it wants to use, whether a Boost library or a C++ standard library equivalent. If I create DLL A which uses Boost regex in its interface and DLL B which uses the C++11 std::regex in its interface, naturally I can't mix them in the sense of trying to pass a Boost regex object to a library that expects a std::regex object or vice versa. As far as actually loading both libraries that in itself should cause no problems AFAICS.

...

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.

I agree that GCC providing auto-linking would be good. But even without auto-linking I think that Boost Build already might have some way to "name" a library based on its compile time parameters.

...

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

I know your opinion about a separate Boost for C++11 libraries. My solution is different. I think libraries for C++11 can coexist in Boost with libraries supporting C++03. I see nothing wrong with the ability of header-only libraries being used in dual mode with my macros. As far as built libraries if Boost could come up with a naming solution so that the C++11 version of a library has a slightly different name than its C++03 counterpart I think that will work fine. Most of the talk about the problems of my macro system presupposes that programmers using Boost will mistakenly try to use a C++11 version of a library during a C++03 mode build and vice versa, and therefore the system must be flawed. Naturally I don't agree but I do understand the reticence of others to accept a dual mode system such as I am proposing.