On Mon, Jun 2, 2014 at 5:10 PM, Nelson, Clark <[email protected]> wrote: >> My understanding falls short in trying to understand the >> difference in >> (possible) recommendation of __has_cpp_attribute and the non- >> recommendation >> of __has_feature, where recommending it would seem to be >> consistent. If it's >> too much, just let me know and I'll stop trying to understand. > > OK, I didn't realize until now that your concern was about the apparent > inconsistency between not recommending __has_feature and recommending > __has_[cpp_]attribute. > > Would it be fair to restate your questions as, why are we recommending > something like __has_attribute when we didn't recommend __has_feature? > > (Actually, whether that's the exact sense of your question or not, I think > that's a very, very important question.)
I believe __has_[cpp_]attribute will have the same concerns as __has_feature regarding preprocessor separation. There's nothing intrinsic about attribute knowledge within the preprocessor like there is with __has_include. In Clang, the preprocessor requests information about attribute presence from another layer within the compiler. We basically had to shift attribute knowledge down a layer to accomplish this. That being said, checking for the presence of this macro has sufficed within our own code base with: #ifndef __has_attribute # define __has_attribute(x) 0 #endif (Which may be sufficient justification for __has_feature as well.) ~Aaron _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
