On 15/01/2014 11:41, Alp Toker wrote:
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.
To be clear, this isn't just about naming. The syntaxes will also end up
differing if we end up with disparate "C++ attributes", "OpenMP
attributes", "OpenCL attributes" (?), "C attributes" -- potentially a
bunch of different specifications and quirky parse rules with no way out.
We can do better than that by taking charge of the situation and setting
a decisive precedent: This proposal introduces generalized attributes
suitable for use in most C-like languages.
Alp.
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
