Boost logo

Boost :

Subject: Re: [boost] [config] Using SD-6 macros
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-12 12:53:22


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-recommendations
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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk