Date: Sun, 23 Jun 2013 20:19:15 -0400
I have an alternate suggestion for the __cpp_lib_header_* macros.
If a library provide needs to update a header (e.g., <utility> to define something like __cpp_lib_header_optional), why don't we just require them to provide the <optional> header, and if they don't implement the feature the complete contents of the file would be:
#define __cpp_lib_header_optional 0
John.
On Jun 21, 2013, at 8: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).
>
> 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)
> <cpp14.htm>_______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
If a library provide needs to update a header (e.g., <utility> to define something like __cpp_lib_header_optional), why don't we just require them to provide the <optional> header, and if they don't implement the feature the complete contents of the file would be:
#define __cpp_lib_header_optional 0
John.
On Jun 21, 2013, at 8: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).
>
> 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)
> <cpp14.htm>_______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
Received on 2013-06-24 16:06:10