On 6/13/2015 1:28 PM, John Maddock wrote:
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 agree that is a good argument against using those macros. There are some solutions, but they all entail inconvenience to the user of config. But until an individual case might be considered I will refrain from suggesting any possible solutions.
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).
Good.
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.
Understood.
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.
You chided me for not being specific so now I will chide you. Please point out to me one case or more where the SD-6 implementation is buggy in this respect. I don't mean that the header is buggy, because that's something that config rightly deals with, but that __has_include tells you that a header exists where it does not. I don't think that situation exists and if it did it would be a serious compiler implementation of an SD-6 implementation error. Just to finish what I hope is more of an agreement than a disagreement about anything regarding SD-6, as I understand you in this area and I believe you understand me, I am not blindly just advocating SD-6 to tell us everything about everything it can and then just have config just accept it as the final word. I got a lot of flac <g> when I queried in the libc++ and libstdc++ mailing lists to find out how to decide if shared_mutex was part of any given library implementation either now or in the future. The answer I received from libc++ was an absolutely unequivocal one that SD-6 is the only way you will ever find out with certainty, other than an empirical test with a particular compiler's implementation that uses libc++, whether a libc++ implementation supports any given standard library feature. With libstdc++ I received much the same answer to use SD-6 in the future, even though I can plainly see now that gcc 4.9.n includes standard_mutex but SD-6 is not implemented until gcc-5.1. With Dinkumware I could not find out anything, but evidently Dinkumware is VC++ for all Boost's intents and purposes so what is decided is based on VC++ releases. Still even here I feel like its pretty difficult since it seems all empirical with each VC++ release. I felt, not entirely naively, that SD-6 where appropriate, would be a solution.
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.