On 6/12/2015 12:06 PM, John Maddock wrote:
On 12/06/2015 16:21, Edward Diener wrote:
I realize I may be late to the discussion, but what is the reason why Boost.config does not use the SD-6 macro functionality as the first check for all C11 and C14 related configuration options ?
We haven't needed to, and until recently we haven't had implementations to check against. So "history" basically.
Some of it, although very clever, seems like educated "guesswork". Isn't it better if the compiler tells us what is omplemented ?
Plus for compiler features, Clang has __has_feature.
OK, that's reliable, as long as the __has_feature we want to check is actually implemented for a given clang release. Of course that's no different than SD-6 except that has_feature is just clang and SD-6 is meant for everybody.
For std lib features, we're sort of screwed though - you can't check the SD6 macros without including the std lib header first - and given that we've already gone to great lengths to make it as lightweight as possible, including the whole std lib just to check the SD6 macros is not going to happen.
About what std lib features are you speaking ? Most of the things I see at https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendat... are predefined. Are you saying that because the compiler implementations of SD-6 most likely have to include standard library headers in order to implement SD-6 correctly that we should avoid using SD-6 ?
Plus as things stand, I don't see what we gain by duplicating macros which can be checked directly anyway?
I do not believe the direct checks are as reliable as SD-6. If I look at libcpp.hpp we are just checking __cplusplus for a bunch of c11 features and libraries. That seems pretty hit and miss to me. When I asked about a way to check libc++ features for any given libc++ release in the clang mailing list the answer was to use SD-6 as a first line of checking. In libstdcpp3.hpp we are doing a much cleverer way of checking, but again when I asked about it on the gcc developers mailing list I was told to use SD-6 if it was available first. I understand all the work you and others have put into Boost.config and I am not suggesting that we replace all of Boost.config's checking simply by SD-6, since it is likely to be ages before every compiler supports SD-6, but SD-6 seems like a much more reliable first way of checking a number of features/headers than we are now doing.