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