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