Subject: Re: [SG10] Draft: ready for the mid-term mailing?
From: Richard Smith (richard_at_[hidden])
Date: 2013-06-23 19:29:53
In the __has_include section:
// To avoid problem with compilers not having this macro.
#if defined(__has_include) && __has_include("myinclude.h")
I believe this is quoted from the Clang manual, but it's bogus: if
__has_include is not available, the preprocessor will reject the
expression, because after substitution its controlling expression is 0
&& 0("myinclude.h"). Suggestion: replace the above #if line with:
#define __has_include(...) 0
On Fri, Jun 21, 2013 at 5:52 PM, Nelson, Clark <clark.nelson_at_[hidden]> wrote:
> Here, just in time for the weekend (in my time zone), is a draft fresh out
> of the oven.
> Basically all of the substantive changes relative to what I sent out after
> Wednesday's meeting are related to __has_include, for which you can search.
> In particular, since I received no responses to my last message explaining
> why I think the __cpp_lib_header_* macros are important, I have left them
> in. But I have moved them to the <utility> header (having heard no objection
> to that idea).
I feel uncomfortable about this; I do not want us to propose two
different ways to check for the presence of a standard header.
What advice will we give to programmers who want to portably test for
these headers? If we want to support a combination of old compiler and
new library, it seems that we must advise them to check for the
__cpp_lib_header_* macro, since that will work for more
implementations. But I'm also unconvinced this is a real concern -- to
the extent that an interim period exists between a user obtaining a
C++14 library which implements our recommendations and them obtaining
a compiler which implements our recommendations, I'm not sure we need
to cater to that period.
If we decide that __has_include is not a full solution for feature
tests for the standard headers (which I think is what we're saying if
we include the __cpp_lib_header_* macros), then I don't think SG10 is
the right vehicle to drive implementation adoption of it.
> So there are two ways by which we recommend it be possible to test for
> these new headers. That is supposed to be clear from the way the table is
> laid out, but I'm afraid that there are too many different subtleties in
> what I've tried to imply through the table layout. I'm going to experiment
> with making the subtleties clearer by adding footnotes.
> Don't forget that the deadline for the mid-term mailing is one week from
> today, so we're getting close to the wire.
> Clark Nelson Vice chair, PL22.16 (ANSI C++ standard committee)
> Intel Corporation Chair, SG10 (C++ SG for feature-testing)
> clark.nelson_at_[hidden] Chair, CPLEX (C SG for parallel language extensions)
> Features mailing list
SG10 list run by email@example.com