On 6/13/2015 4:12 AM, John Maddock wrote:
Each particular check does not include the whole std lib. Are you really objecting to including individual headers for individual features if there is no absolutely reliable method otherwise ?
Well the question is "is there a reliable method otherwise"? There may well not be for clang/libstdc++ but for everything else I'm fairly sure there is.
Unless individual compilers and/or standard libraries continue to provide "a reliable method" for future releases outside of SD-6 it sure seems easier to me to rely on an SD-6 implementation as the first check.
BTW this is not my objection so much as I can tell you from past experience that users absolutely do complain if Boost.Config starts #including too much. Were we to duplicate all the SD6 macros then we would have to include all of:
utility memory functional type_traits chrono string map set iterator algorithm complex iomanip shared_mutex
I think it is the fault of users to complain about this. Clearly SD-6 did not think that including a header to find out if a particular feature was available or not is not a great inconvenience.
Are you suggesting that would be a good idea for a library that just wants to check if |BOOST_NO_LONG_LONG is set?
Agreed in principal but I don't think it can be avoided easily in reality.
There are obviously other solutions - separate headers for this stuff for example - but we're not there yet - remember that we only tend to add new macros when libraries actually need them, not as vaporware. |
Agreed.
So we let each Boost library and each end-user of Boost go through the mechanism of checking a C++14 feature using SD-6 themselves rather than doing it once in Boost.config ?
There's little difference:
#ifdef |__cpp_lib_integer_sequence https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendat...
against
#ifndef BOOST_NOCPP_LIB_INTEGER_SEQUENCE
Obviously if we find SD6 implementations buggy then we'll have to revisit. |
I would have thought the correct SD-6 code for this is: #ifdef __has_include #if __has_include(<utility>) #include <utility> #if __cpp_lib_integer_sequence #endif #endif #endif
Your feeling then is that we should not try to do anything in Boost.config for C++14 features/headers or possiblly C++17 features/headers if they are already covered by SD-6 ? What about C++11 features and headers we already have in Boost.config ? You don't see them as being more reliable if we go the SD-6 route and only fallback to our current implementation if SD-6 is not available ?
Please be specific, there are already some SD6 checks in the compiler configs I believe, and like I said for std lib checks are you suggesting that SD6 is better / less buggy than __has_feature for clang?
I mentioned libc++, Even the checks in libstdc++ are heavily reliant on interpreting gcc "versions" from other compilers which use libstdc++, like clang. Suppose other compilers start using libstdc++ ? Looking at Dinkumware we are currently relying on an internal version number for C11 features. I am not really criticizing as I know how much work you and others have done to make config work as well as it does.
For GCC we need the version check to verify that SD6 exists, and then... *nothing happens*, as we don't don't set anything anyway for gcc-5.1 as far as I can remember.
You don't ever have to do a version check for SD-6 if you just try out an SD-6 macro. If it is not defined you just move on to what we are doing now in Boost.config, for any given situation. I totally agree that we should look at each config feature individually to see if there is an SD-6 equivalent we can possible use. I also agree that as always we shouldn't just be blindly adding features to config just because they exist if nobody is asking for them. My point of view is that for any config feature which has an SD-6 equivalence, unless you absolutely believe that there is a fail-safe method of testing for that feature for a given compiler and/or standard library both now and in the future, we can use SD-6 as the first check for the feature that we do before we move on to our current check if the SD-6 feature check does not exist. I view this as more robust now and for the future.