views:

1244

answers:

8

Recently voted into the C++0x working paper was an attribute syntax. This syntax provides a way to specify other pieces of information to the compiler. The Committee Draft also includes several standard attributes.

The syntax is to wrap the attribute list in double square brackets, e.g. [[noreturn]]. These attributes can be "namespaced" in the sense that they are allowed to use :: to avoid name clashes (for instance, you might have [[windows::dllimport]]), and can take parameters. They can be applied to virtually anything - types, objects, functions, statements, and so are extremely versatile. The current draft specifies the follwing attributes: [[align(number or type)]] to specify an object's alignment, [[noreturn]] to hint to the optimizer that a function won't return, [[final]] to ask the compiler to prevent overriding (in this regard though, an implementation may ignore it), and [[carries_dependency]] to indicate that the function carries a dependency (it's an optimizer thing added with the threading system that I don't really understand myself).

A representative from Microsoft has stated that Microsoft "refuses" to implement these attributes (quotation from the minutes of the last meeting). This is a travesty, as a major compiler not implementing such an important feature is a disaster for the standard (export is different in that it is extremely difficult to use and very rare; these attributes stand to become on of the most easy-to-use features of C++0x)

So I ask you what attributes you guys would like. Perhaps we can take some of the most popular ones and attempt to get a vendor-neutral extension standard going, and hopefully get a very powerful addition to C++.

+8  A: 

Personally, two I'd like to see are [[deprecated]] and [[pure]]. Deprecation is a popular attribute in existing compilers, and pure specification provides a very useful optimizer hint (and does not obsolete constexpr at all, it in fact reinforces it to a large extent). [[dllimport]] and [[dllexport]] will be important, but I think would be better off in another namespace (as above). Having [[nonnull]] as a variable attribute would be awesome, and [[nothrow]] to allow non-throwing optimizations (as opposed to throw() which requires the unexpected exception mechanisms) would be cool, The thing about such optimizing attributes is they require compiler support (particularly something like [[nonnull]] because you will (naturally) eschew runtime checks in favor of the attribute, which will go badly if the compiler just ignores them.

These attributes were largely stolen from GCC's list of attributes, because I'm feeling really uncreative at the moment.

coppro
+7  A: 

[[internal]] for functions / classes that should only be used by code that's in the same namespace like those functions / classes.

Johannes Schaub - litb
+1  A: 

If I understand correctly this is a standardized format of __attribute__(( )) [GNU], and __declspec() [MS].

In case the attributes were developer extensible and available through some reflection mechanism (see Java annotations :-) it would open up loads of possible (mis)uses, but if I read the propsal correctly the attributes are only be available to the compiler. Maybe LLVM could make good use of them though.

divideandconquer.se
C++ has no reflection system for a very good reason (implementing a reflective type system would take a lot more work), but there is no reason why attributes would have to be hidden from the code at runtime. And it doesn't make that much of a difference with the advent of concepts, in my opinion.
coppro
+14  A: 

[[override]]

The attribute would specify that a virtual function must override a virtual function and cannot of itself create a new one.

class A
{
   virtual void foo( int i) const;
};

class B : public A
{
   [[override]]
   virtual void foo( int i); // compile error here
};

How many people have had that bug. Especially when the class A is in 3rd party library, where the signature changed in an update.

I'm not bitter.

caspin
would be very useful!
vividos
I personally don't think that's half as bad as the far more subtle virtual overload issue, which is more difficult to work with attributes (especially across multiple vendors)
coppro
This attribute and a few others supporting it have now been finalized in the standard. It's good to know that someone on the standards committee thought of this as well. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm
caspin
I'm pleased to see this, having made extensive use of Java's @Override annotation before.
Michael Myers
+1: "I'm not bitter." ;-)
Chris
+2  A: 

Another idea I just came up with is to make attributes specifying important information about class types, like [[trivial]] or [[aggregate]]. Then the compiler catches if your class doesn't meet that requirement. Another one could be [[constexpr]] placed on a statement to indicate it should be evaluated at compile-time and give a warning if it cannot (on a declaration to apply to the variable, on an assignment to apply to the RHS, or on a block to say this should apply to every element of it). You could also put [[noreturn]] on a block to indicate control won't flow naturally from it - it will exit by break, goto, or some other method of transferring control without falling off the end. Also, [[synchronized]] to work much like the Java keyword of the same name.

coppro
+1  A: 

Another vote for [[deprecated]] and [[pure]].

+1  A: 

Just a little update: There is a proposal now for [[override]], [[hidden]], and [[check_members]] attributes. They don't affect semantics, but the first two specify that a function must override/hide a base class function (it can be both). [[check_members]] tells the compiler to issue an error if any functions are present that overload or hide without using the appropriate attributes.

coppro
A: 

the fact that they are not making this mechanism extensible as in java or c# means that it will just be a mockery of the real feature

charllls
It is extensible in the sense that compilers can add their own data. It's not like Java or C# attributes as they won't represent actual metadata passed into the program - which is completely natural for C++, just as it has no reflective capabilities (which both of those languages do)I don't think it's fair to call it a 'mockery of the real feature' given that, and given the fact that these attributes exist primarily to help standardize the syntax for the myriad of existing attributes - `__attribute__((pure))`, `__declspect(dllimport)`, and so on.
coppro