[config] Configuring for C++14 and later library features.
Folks, I have an open PR for adding BOOST_NO_CXX14_INTEGER_SEQUENCE (https://github.com/boostorg/config/pull/58). Unfortunately, the correct way to check for std::integer_sequence is to include <utility> and then check for __cpp_lib_integer_sequence. The problem is that we went to some lengths to remove dependencies on <utility> in https://github.com/boostorg/config/pull/40. Further, if we get requests for more such feature-detection macros, we would end up including the whole std lib (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745#recs.cpp14). This doesn't look acceptable to me, but what to do? The only solution I can see is to simply not support these features in Boost.Config, but rather rely on users needing these features checking the std detection macros directly. Which will work up until someone implements a feature without defining the appropriate macro :( Thoughts? Thanks, John.
On Friday 24 April 2015 13:32:36 John Maddock wrote:
Folks,
I have an open PR for adding BOOST_NO_CXX14_INTEGER_SEQUENCE (https://github.com/boostorg/config/pull/58).
Unfortunately, the correct way to check for std::integer_sequence is to include <utility> and then check for __cpp_lib_integer_sequence. The problem is that we went to some lengths to remove dependencies on <utility> in https://github.com/boostorg/config/pull/40. Further, if we get requests for more such feature-detection macros, we would end up including the whole std lib (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745#recs.cpp14).
This doesn't look acceptable to me, but what to do? The only solution I can see is to simply not support these features in Boost.Config, but rather rely on users needing these features checking the std detection macros directly. Which will work up until someone implements a feature without defining the appropriate macro :(
Thoughts?
You could just define the macro based on compiler version. That could be backed by a test which not only checks for __cpp_lib_integer_sequence but for std::integer_sequence itself. PS: I thought it was enough to include any STL header (e.g. cstddef) to get all these macros defined. Isn't it the case? How would one test for a feature that is implemented in a new header?
This doesn't look acceptable to me, but what to do? The only solution I can see is to simply not support these features in Boost.Config, but rather rely on users needing these features checking the std detection macros directly. Which will work up until someone implements a feature without defining the appropriate macro :(
Thoughts? You could just define the macro based on compiler version. That could be backed by a test which not only checks for __cpp_lib_integer_sequence but for std::integer_sequence itself. Compiler version is irrelevant, it's the std lib that matters. I think for most std lib's, yes we could use existing machinery to check this, I'm not sure about clang/libc++ though - _LIBCPP_VERSION appears to be stuck at 1101 and the clang version number is notoriously unreliable. Any clang experts confirm this? PS: I thought it was enough to include any STL header (e.g. cstddef) to get all these macros defined. Isn't it the case? How would one test for a feature that is implemented in a new header? Please see the paper linked to, but basically it suggests using __has_include(<name>). Of course technically, none of this is in the standard, rather it's contained in an ever changing "standing document".
John.
On 4/24/2015 9:32 AM, John Maddock wrote:
Folks,
I have an open PR for adding BOOST_NO_CXX14_INTEGER_SEQUENCE (https://github.com/boostorg/config/pull/58).
Unfortunately, the correct way to check for std::integer_sequence is to include <utility> and then check for __cpp_lib_integer_sequence.
I wouldn't call that the "correct way", it is just **a** way. In particular, it is a "safe way", as in that false negatives are perfectly acceptable (and IIRC neither libc++ nor msvc provide these yet).
This doesn't look acceptable to me, but what to do?
I suggest to do what has always been done so far (craft tests, detect stdlib, set macros explicitly). Is there a reason that I'm missing as for which the traditional approach doesn't fit here? The feature tests from SD-6 are for convenience, there's no point in using them if doing so would be inconvenient. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
I suggest to do what has always been done so far (craft tests, detect stdlib, set macros explicitly). Is there a reason that I'm missing as for which the traditional approach doesn't fit here?
Clang/libc++ appears to have no other reliable mechanism, but it would be nice to be proved wrong. John.
I came up with this idea:
Boost.Config provides header files for each library feature (i.e. one header
per one feature), but
On 4/24/2015 8:32 AM, John Maddock wrote:
Folks,
I have an open PR for adding BOOST_NO_CXX14_INTEGER_SEQUENCE (https://github.com/boostorg/config/pull/58).
Unfortunately, the correct way to check for std::integer_sequence is to include <utility> and then check for __cpp_lib_integer_sequence. The problem is that we went to some lengths to remove dependencies on <utility> in https://github.com/boostorg/config/pull/40. Further, if we get requests for more such feature-detection macros, we would end up including the whole std lib (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745#recs.cpp14).
This doesn't look acceptable to me, but what to do? The only solution I can see is to simply not support these features in Boost.Config, but rather rely on users needing these features checking the std detection macros directly. Which will work up until someone implements a feature without defining the appropriate macro :(
Thoughts?
What is the purpose of Boost.config attempting to not use the C++ standard library ?
What is the purpose of Boost.config attempting to not use the C++ standard library ?
Folks complain if code includes large amounts of "stuff" that's not
used, or purely used for configuration.
To be clear, if we did this via the SD6 macros for all the C++14
features, then we would need to include all of:
<utility>
<functional>
John Maddock wrote:
To be clear, if we did this via the SD6 macros for all the C++14 features, then we would need to include all of:
<utility> <functional>
<chrono> <string> <map> <set> <iterator> <algorithm> <complex> <iomanip> and do this wherever boost/config.hpp is included. IMO this is too "fat" a dependency list for a library that may otherwise include no std lib headers at all.
We should probably inform the working group about this deficiency in SD6. :-)
Peter Dimov wrote:
John Maddock wrote:
To be clear, if we did this via the SD6 macros for all the C++14 features, then we would need to include all of:
<utility> <functional>
<chrono> <string> <map> <set> <iterator> <algorithm> <complex> <iomanip> and do this wherever boost/config.hpp is included. IMO this is too "fat" a dependency list for a library that may otherwise include no std lib headers at all.
We should probably inform the working group about this deficiency in SD6. :-)
I reported the problem a year ago with exactly the above description, but Clark Nelson didn't understand: http://thread.gmane.org/gmane.comp.lang.c++.isocpp.features/17/focus=22 Do bring it up again, though, yes. Thanks, Steve.
John Maddock wrote:
Further, if we get requests for more such feature-detection macros, we would end up including the whole std lib (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745#recs.cpp14).
Heh, almost exactly a year ago: http://article.gmane.org/gmane.comp.lang.c++.isocpp.features/17/match=Boost
Boost.Config does record some library features, and may have to include many headers in order to access the macros, which might be undesirable.
This doesn't look acceptable to me, but what to do?
Bring it up on isocpp.features. Thanks, Steve.
participants (7)
-
Agustín K-ballo Bergé -
Andrey Semashev -
Edward Diener -
John Maddock -
Michel Morin -
Peter Dimov -
Stephen Kelly