Le 30 avr. 2011 à 23:08, Peter Collingbourne a écrit : > On Sat, Apr 30, 2011 at 08:08:06PM +0200, Jean-Daniel Dupas wrote: >> >> Le 29 avr. 2011 à 20:07, Douglas Gregor a écrit : >> >>> >>> On Apr 29, 2011, at 10:44 AM, Peter Collingbourne wrote: >>>> OK, I am fine with introducing a c_ prefix, for the reasons you >>>> point out. But the way I understand it is that __has_feature in fact >>>> has 2 semi-orthogonal purposes: >>>> >>>> 1) To test for support for Clang-specific extensions to the language. >>>> This is the purpose of the non-language-prefixed feature test >>>> identifiers. >>>> >>>> 2) To test for Clang support for language features which have been >>>> standardised in the current language. This is the purpose of the >>>> language-prefixed feature test identifiers. >>>> >>>> However, there is a gap here in that there is no way to test for >>>> the existence of Clang-specific language extensions which have been >>>> standardised in other languages. For example, generic selections >>>> can be used to implement an OpenCL runtime library using Clang. >>>> Since OpenCL is based on C99, generic selections would be classified >>>> as an extension. This makes it impossible to test for that extension. >>>> >>>> One solution to this problem is to have 2 feature test identifiers >>>> for each standardised feature (e.g. "c_generic_selections" and >>>> "generic_selections"), each serving the 2 purposes mentioned above. >>>> The disadvantage of this approach would obviously be the doubling up of >>>> language feature identifiers. Also, as you point out "static_assert" >>>> would be ambiguous. >>>> >>>> An alternative solution would be to introduce another macro, say >>>> __has_extension, which takes the same feature test identifiers >>>> as __has_feature. __has_extension would test the features of >>>> the compiler alone (approximately serving purpose 1) while >>>> __has_feature tests the features of the compiler together >>>> with the current language (approximately serving purpose 2). >>>> >>>> So for example __has_feature(c_generic_selections) could be >>>> used to test for support for generic selections in C1X while >>>> __has_extension(c_generic_selections) could be used in any language. >>>> I would imagine that __has_extension should act identically to >>>> __has_feature if -pedantic-errors (or perhaps -pedantic) is enabled. >>>> >>>> Please let me know what you think. >>> >>> I think that __has_extension is an *excellent* idea! >> >> I tried to implements this new suggestion. >> The has_feature variants are bound to the selected language and returns true >> only when compiling as C1X, and has_extension always returns true. >> Is this what you had in mind ? > > __has_extension should be a superset of __has_feature, so it should > also include the C++ and C++0x features, as well as the Clang specific > extensions. This can be done trivially by calling HasFeature from > HasExtension. > > I began an implementation (see patch), but this is incomplete since it > includes no tests. I also haven't surveyed all of the C++0x features > to see which are supported as extensions to C++98. If you like, > you can extend the patch to add the correct set of C++0x features as > well as tests. >
I'm not very familiar with C++0x features supported as extensions but a quick look in diagnostics gave 3 more features. Someone familiar with this part should definitively review this list. I also add a couple of simple tests, for c1X features and has_extensions. -- Jean-Daniel
has_extension.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
