> > 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.] > > Good points. > > I agree that those are more important than consistency, especially > as it can > be more consistent in the future if __has_builtin() or anything > else is > added in the future. > > Then only the language/library feature tests would be > 'inconsistent' by the > absence of __has_feature().
As always, consistency is a multi-edged sword. Not everything can be consistent with everything else; you have to pick your "consistency target" carefully to achieve the goals you really want. In my mind, there is a very significant way in which __has_include is inconsistent with the others: its argument identifies a physical file, which either is or is not available to be included, objectively. On the other hand, the argument to __has_feature basically identifies a concept, and whether an implementation has a feature is often a subjective call. The question of whether an implementation recognizes an attribute with a given name can be answered objectively, I suppose, but it seems to me there's still some wiggle room, because the attribute may not do exactly what I think it should do. But then I suppose it's theoretically possible for an implementation to have a header named <optional> whose contents do what <stddef.h> is supposed to do. For me, the only thing that's really consistent between __has_include, __has_feature and __has_attribute is that their syntaxes all use parentheses. And for my money, that puts __has_feature and __has_attribute at a (slight) disadvantage compared with just constructing a macro name using an underscore delimiter instead. Clark _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
