Date: Fri, 3 May 2013 14:34:15 -0700
This looks like a great start.
1) Clang has separate __has_feature(X) and __has_extension(X) macros. The
former determines whether the feature is available as part of the enabled
language standard in the current compilation, and the latter determines
whether it's available (possibly as an extension) in the current
compilation. The difference is that use of __has_extension(X) features may
generate warnings (and, with -Werror or -pedantic-errors, may generate
errors).
Which of these is the behavior we want for these feature-test macros? In my
experience, __has_feature(X) is what you want when determining whether to
use a language feature in normal code, but __has_extension(X) is what you
want when determining whether to use a language feature in a system header.
2) At what point will we consider these names stable enough for compiler
vendors to start providing them? Are we OK with compilers starting to
define these today? (FWIW, I think this is fine.)
3) Can we split a __cpp_decltype_auto out of __cpp_return_type_deduction?
These are essentially two separate, orthogonal features, which just happen
to have been added in the same paper. There's a decent chance that Clang
3.3 will ship with the former but not the latter.
4) I agree with Jens that a feature-test macro for __cpp_new_merging is
unlikely to add any value.
On Thu, May 2, 2013 at 3:33 PM, Nelson, Clark <clark.nelson_at_[hidden]>wrote:
> I've attached the work I've done so far towards drafting a feature-testing
> recommendation for C++14. The prose is just copied from my original paper
> (N3435), as a sort of place-holder for an introduction. The real work went
> into the table.
>
> FYI, part of my idea at this point is to include as much useful
> information in the table as will fit. Hopefully, the table will eventually
> become a fairly well-known resource; if so, more people will be exposed to
> the general idea of standard feature-test macros, and to the specific macro
> names.
>
> Let's see how well the attachment makes it through our reflector.
>
> (FYI, I may not see any comments on this until Monday. I'm really not
> ignoring you. :-)
>
> Clark
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>
>
1) Clang has separate __has_feature(X) and __has_extension(X) macros. The
former determines whether the feature is available as part of the enabled
language standard in the current compilation, and the latter determines
whether it's available (possibly as an extension) in the current
compilation. The difference is that use of __has_extension(X) features may
generate warnings (and, with -Werror or -pedantic-errors, may generate
errors).
Which of these is the behavior we want for these feature-test macros? In my
experience, __has_feature(X) is what you want when determining whether to
use a language feature in normal code, but __has_extension(X) is what you
want when determining whether to use a language feature in a system header.
2) At what point will we consider these names stable enough for compiler
vendors to start providing them? Are we OK with compilers starting to
define these today? (FWIW, I think this is fine.)
3) Can we split a __cpp_decltype_auto out of __cpp_return_type_deduction?
These are essentially two separate, orthogonal features, which just happen
to have been added in the same paper. There's a decent chance that Clang
3.3 will ship with the former but not the latter.
4) I agree with Jens that a feature-test macro for __cpp_new_merging is
unlikely to add any value.
On Thu, May 2, 2013 at 3:33 PM, Nelson, Clark <clark.nelson_at_[hidden]>wrote:
> I've attached the work I've done so far towards drafting a feature-testing
> recommendation for C++14. The prose is just copied from my original paper
> (N3435), as a sort of place-holder for an introduction. The real work went
> into the table.
>
> FYI, part of my idea at this point is to include as much useful
> information in the table as will fit. Hopefully, the table will eventually
> become a fairly well-known resource; if so, more people will be exposed to
> the general idea of standard feature-test macros, and to the specific macro
> names.
>
> Let's see how well the attachment makes it through our reflector.
>
> (FYI, I may not see any comments on this until Monday. I'm really not
> ignoring you. :-)
>
> Clark
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>
>
Received on 2013-05-03 23:34:18