On 12/06/2015 17:53, Edward Diener wrote:
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 ?
Sure, but like I said, this has only been very recently supported.
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 ?
No, I'm saying we can't check the __cpp_lib* macros without: a) using __has_include to check the header exists, then b) actually including the header.
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.
What I mean is: If we don't have a macro for something, but SD6 does, then the user can just check SD6 without using Boost.Config at all.
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. Looks like we could do better for some of those: where the compiler is clang anyway. Note the comment though that some of the headers exist, but are broken. Given that there are no useful libc++ (or clang) version numbers available, I don't know what we do about that :( 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.
For GCC5 and later yes, but again, there's very little overlap between our config macros and SD6 lib macros at present - GCC5 basically doesn't define anything much in libstdcpp.hpp? John.
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost