Date: Mon, 9 Jun 2014 16:08:13 -0700
On Mon, Jun 9, 2014 at 3:39 PM, Stephen Kelly <steveire_at_[hidden]> wrote:
> Nelson, Clark wrote:
>
> >> > Would it be fair to restate your questions as, why are we
> >> recommending
> >> > something like __has_attribute when we didn't recommend
> >> __has_feature?
> >
> > I was actually hoping someone would provide an answer to that question.
>
> Can we ask the person who proposed it?
I don't see any solid reasons to avoid a function-like attribute detection
macro. Yes, it requires preprocessor support beyond just defining some
extra macros, but does that actually matter to any implementor? We already
crossed that bridge with __has_include.
As for __has_cpp_attribute, it provides a way to query non-standard
attributes as well as standard ones. Sure, we could define an encoding such
that an implementation can define
__has_cpp_attribute_<attribute-scope-token>_<attribute=name> or similar,
but...
1) That's a *lot* of macros. We might be able to get away with the cost of
the number of macros that SG10 is currently proposing, but I would be
*seriously* concerned about a measurable performance cost (on compiling an
empty file, which is not actually an irrelevant concern) of predefining
hundreds of __has_attribute macros.
2) Either of those identifiers could contain underscores, and there is no
other separator character that works.
[3) It's ugly.]
> I myself am opposed -- weakly -- to the __has_attribute syntax, or some
> > variation thereof, for all the reasons we didn't go with __has_feature in
> > the first place, as I explained a couple of weeks ago.
>
> I favor consistency between the feature test and the attribute test.
>
I agree that there's value in the two being consistent. But I think there
are other concerns that we should be weighing.
I'm still not entirely sold on the argument that took us away from
something like __has_feature(x), but that ship has sailed. The argument
there that holds most weight with me is that features are sometimes
provided by the library instead of the language, and it's easy to portably
define __cpp_whatever but not so easy to portably extend a magical
__has_feature syntax.
I weakly favor __has_foo() for these reasons:
>
> 1) For creating the consistency (at least from the users point of view) of
> all such tests now and in the future being __has_foo().
>
> For example, __has_builtin(is_final) might solve the problem here:
>
> http://www.open-std.org/pipermail/features/2014-May/000176.html
>
> See
>
> http://thread.gmane.org/gmane.comp.compilers.clang.devel/34252
>
>
> 2) For making it harder for users to make mistakes such as
>
> #ifdef __cpp_foo
> #endif
>
> when they meant
>
> #if __cpp_foo
> #endif
>
> or
>
> #if __cpp_foo > 201404
> #endif
>
> or
>
> #if __cpp_foo >= 201404
> #endif
>
>
>
> I think __cpp_foo is fine because it might be easier to implement. However,
> I would request consistent prefixes/namespacing to allow for growth in the
> classes of tests recommended (eg builtins):
>
> http://thread.gmane.org/gmane.comp.lang.c++.isocpp.features/11
>
> Thanks,
>
> Steve.
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>
> Nelson, Clark wrote:
>
> >> > Would it be fair to restate your questions as, why are we
> >> recommending
> >> > something like __has_attribute when we didn't recommend
> >> __has_feature?
> >
> > I was actually hoping someone would provide an answer to that question.
>
> Can we ask the person who proposed it?
I don't see any solid reasons to avoid a function-like attribute detection
macro. Yes, it requires preprocessor support beyond just defining some
extra macros, but does that actually matter to any implementor? We already
crossed that bridge with __has_include.
As for __has_cpp_attribute, it provides a way to query non-standard
attributes as well as standard ones. Sure, we could define an encoding such
that an implementation can define
__has_cpp_attribute_<attribute-scope-token>_<attribute=name> or similar,
but...
1) That's a *lot* of macros. We might be able to get away with the cost of
the number of macros that SG10 is currently proposing, but I would be
*seriously* concerned about a measurable performance cost (on compiling an
empty file, which is not actually an irrelevant concern) of predefining
hundreds of __has_attribute macros.
2) Either of those identifiers could contain underscores, and there is no
other separator character that works.
[3) It's ugly.]
> I myself am opposed -- weakly -- to the __has_attribute syntax, or some
> > variation thereof, for all the reasons we didn't go with __has_feature in
> > the first place, as I explained a couple of weeks ago.
>
> I favor consistency between the feature test and the attribute test.
>
I agree that there's value in the two being consistent. But I think there
are other concerns that we should be weighing.
I'm still not entirely sold on the argument that took us away from
something like __has_feature(x), but that ship has sailed. The argument
there that holds most weight with me is that features are sometimes
provided by the library instead of the language, and it's easy to portably
define __cpp_whatever but not so easy to portably extend a magical
__has_feature syntax.
I weakly favor __has_foo() for these reasons:
>
> 1) For creating the consistency (at least from the users point of view) of
> all such tests now and in the future being __has_foo().
>
> For example, __has_builtin(is_final) might solve the problem here:
>
> http://www.open-std.org/pipermail/features/2014-May/000176.html
>
> See
>
> http://thread.gmane.org/gmane.comp.compilers.clang.devel/34252
>
>
> 2) For making it harder for users to make mistakes such as
>
> #ifdef __cpp_foo
> #endif
>
> when they meant
>
> #if __cpp_foo
> #endif
>
> or
>
> #if __cpp_foo > 201404
> #endif
>
> or
>
> #if __cpp_foo >= 201404
> #endif
>
>
>
> I think __cpp_foo is fine because it might be easier to implement. However,
> I would request consistent prefixes/namespacing to allow for growth in the
> classes of tests recommended (eg builtins):
>
> http://thread.gmane.org/gmane.comp.lang.c++.isocpp.features/11
>
> Thanks,
>
> Steve.
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>
Received on 2014-06-10 01:08:15