On 15/01/2014 06:04, Nico Weber wrote:
Does gcc allow this for C? Is C planning on standardizing this?
The impression I get is that everybody's doing it but nobody's talking about it. Yet.
ISO C is reactionary so if we set a sensible standard there's a reasonable shot at getting it adopted. Likewise OpenMP and other dialects -- they'll go with the mainstream.
This is also why we should use a name that's already recognised like "generalized attributes." Language bodies simply won't accept a foreign name like "C++ attributes" -- it has never happened before, given how fiercely independent these committees are -- so they'll end up each going their own route, choosing their own names. It's a better plan to consolidate proactively here.
My view is that it matters because we're working with the people designing these standards and they respect our decisions when we put time into getting them right.
Of there'll always be those with Richard Smith's point of view that "we really don't need to worry about theoretical future C17 or OpenMP constructs now" -- but assuming we do care (and I do), these are issues that matter.
Alp.
On Tue, Jan 14, 2014 at 5:50 PM, Richard Smith <[email protected] <mailto:[email protected]>> wrote:On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith <[email protected] <mailto:[email protected]>> wrote: On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker <[email protected] <mailto:[email protected]>> wrote: This patch generalizes C++11 attributes for use in C and C-like dialects, and additionally enables the new syntax as an extension to C11. Why do you allow this by default in C11? And conversely, why not in C90 / C99? I think maybe this was unclear. I'd prefer one of these two options: 1) A -fcxx-attributes argument (or similar) to enable C++ attribute syntax outside C++ (and either do or don't allow them by default in C++98), or 2) C++ attributes available by default in all language modes. I'd prefer the first option (defaulting to following the language standard more strictly) -- I think this would be the first time we enabled a C++ language feature in C modes, if we went with the second option. If we're going to allow these anywhere by default, C++98 would seem like a good place to start. I don't believe they introduce any ambiguities outside of Objective-C(++), and we already disambiguate those cases. (There's an ambiguity with lambdas, but we don't need to address that until/unless we allow lambdas in C++98.) All features are carried forward from C++11, including usage on declarations, attributed statements, scoped attribute names, GNU attribute aliases and the clang-specific attribute namespace. A new feature detection macro is provided, breaking from the usual c/cxx prefix convention in order to facilitate portable detection in C++ and C modes: __has_feature(attributes) - 1 in C++11, otherwise 0. __has_extension(attributes) - 1 in C++11 and C11, otherwise 0. This is already available as __has_feature(cxx_attributes); using __has_extension(cxx_attributes) in C would seem to be the right approach here (we're allowing C++ attributes as an extension in C). This is what we already do for C99 and C11 features which we accept in C++. The new warning flag -W(no-)generalized-attributes suppresses the new extension warning in C. The same flag can also be used to selectively disable attribute compatibility warnings produced by the pre-existing -Wc++98-compat option. OK, so this is why you wanted us to pick a name for this feature; you're going to use it as a diagnostic name. I think this should be called -Wc++-attributes, to match our existing compatible-for-all-time feature name cxx_attributes. We can add an alias to a better name if we ever need one, but for now, we're pretty clearly allowing a C++ feature in C, so calling it "c++-something" makes sense to me. Newly added tests have been shared with C++11 where possible to ensure consistency between language modes. Does this do the right thing for (for instance) struct S { [[ gnu::aligned(8) ]] int n; }; ? (Structs use different parsing code in C and C++. ) _______________________________________________ cfe-commits mailing list [email protected] <mailto:[email protected]> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
-- http://www.nuanti.com the browser experts _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
