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
Only if you're being unreasonably pedantic - I don't think there are any compilers supporting SD6 that don't have <utility> - or indeed any of the other headers mentioned in SD6 for that matter. The point is, if you're the end user, you're going to have to include <utility> or whatever anyway, so including it before checking the SD6 macro for whatever "advanced" feature you're interested in loses you nothing. Boost.Config on the other hand would have to #include everything regardless of whether it's being used or not.
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.
Edward, I'm sorry but this is all hypothetical at present - we will do whatever needs to be done to make things work - that will surely include some use of SD6 (especially the compiler-predefined macros). What I'm trying to get across is that there is little overlap between current Boost.Config macros and SD6 - so the opportunities for simplification of what we have are extremely thin on the ground. And you're correct that the libstdc++ config is pretty darn tricky - but SD6 doesn't help us a bit for say Clang on libstdc++ - we can't use simple __has_include to check for the existence of std lib headers because many were hopelessly buggy when first introduced. We can't use any compiler intrinsic defines (SD6 or otherwise) because they have no relation to the std lib. We can't use libstdc++ version numbers because they're simple release dates that have no correspondence to GCC version and/or feature sets. So that leaves us back with trying to infer the GCC release as now - and once you have that you have the info you need to configure anyway.
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.
Unfortunately that's not quite true - sometimes you can't reliably include a std lib header even when __has_include reports true as noted above. John.
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost .