On Thu, Jan 24, 2013 at 4:40 PM, Nelson, Clark <clark.nelson_at_[hidden]> wrote:
> We can't ignore clang, as it is the only popular implementation that has done anything systematic about language feature-testing. But what clang has already done about C++11 (i.e. the past) isn't directly applicable to the future; it's only a model. On the other hand, it's very instructive, especially as regards granularity.
>
> To me, the most obvious question is whether testing for the presence of a feature should use a function-like syntax, or just an identifier. From a programming perspective, there's no practical difference between these two alternatives:
>
> __has_feature(cxx_alignas)
> __has_feature_cxx_alignas
>
> On the other hand, if the function-like syntax is used to test for a feature, somehow there has to be a definition of the function-like macro, or simply testing for the feature is likely to be an error. That would either limit the usefulness of feature-testing, or require users to add boilerplate to conditionally define the function-like macro.

IIRC, Clang chose to have only a single identifier here for
preprocessing performance reasons; there were concerns that having
(effectively) a large set of predefined macros would be expensive,
especially for very small translation units (configure tests, for
instance), but I don't know if the performance difference was ever
measured.

The boilerplate is three lines of code (usually in one project-wide
header), which doesn't seem like much given that each use of a test
macro will typically add more than that.

The __has_feature(x) approach can also be used outside of a
preprocessor constant expression, since it can produce 0 for an
unavailable feature, but I don't imagine that would be a particularly
useful property.