This was discussed in EWG this afternoon. One of the principal objections to this idea has been the complications involved in implementing it with a separate preprocessor. But no one could think of any popular C++ implementation that actually uses a separate preprocessor. It was also pointed out that we've been making more and more changes that mean that a standard preprocessor for C can't be used for C++, including raw string literals in C++11 and apostrophe as a digit separator in C++14. (And for that matter bool in C++98.) Using a separate preprocessor is just getting harder and less likely. It was also pointed out that, if the preprocessor is integrated with the parser, a single table of attributes can be used for both parsing and feature-testing.
Tom Plum's idea of using #undef as a workaround for a case where an implementation of a feature is too buggy to use was also mentioned. But it was pointed out that SD-6 doesn't promise that our recommended predefined macros can be #undef-ed, and EDG's implementation, at least, doesn't allow them to be. In any event, there's really no way any specification can place additional constraints on an implementation that doesn't conform to it. I didn't bother to record the numbers of the straw poll. Even Tom changed his mind and voted for __has_cpp_attribute, and no one voted against it. (If I had bothered to raise my hand, it would have been for "neutral".) So it looks like we'll be adding __has_cpp_attribute to our recommendations. -- Clark Nelson Vice chair, PL22.16 (ANSI C++ standard committee) Intel Corporation Chair, SG10 (C++ SG for feature-testing) [email protected] Chair, CPLEX (C SG for parallel language extensions) _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
