C++ Attributes (Using the GNU Compiler Collection (GCC)) (original) (raw)

Some attributes only make sense for C++ programs.

abi_tag ("tag", ...) ¶

The abi_tag attribute can be applied to a function, variable, or class declaration. It modifies the mangled name of the entity to incorporate the tag name, in order to distinguish the function or class from an earlier version with a different ABI; perhaps the class has changed size, or the function has a different return type that is not encoded in the mangled name.

The attribute can also be applied to an inline namespace, but does not affect the mangled name of the namespace; in this case it is only used for -Wabi-tag warnings and automatic tagging of functions and variables. Tagging inline namespaces is generally preferable to tagging individual declarations, but the latter is sometimes necessary, such as when only certain members of a class need to be tagged.

The argument can be a list of strings of arbitrary length. The strings are sorted on output, so the order of the list is unimportant.

A redeclaration of an entity must not add new ABI tags, since doing so would change the mangled name.

The ABI tags apply to a name, so all instantiations and specializations of a template have the same tags. The attribute will be ignored if applied to an explicit specialization or instantiation.

The -Wabi-tag flag enables a warning about a class which does not have all the ABI tags used by its subobjects and virtual functions; for users with code that needs to coexist with an earlier ABI, using this option can help to find all affected types that need to be tagged.

When a type involving an ABI tag is used as the type of a variable or return type of a function where that tag is not already present in the signature of the function, the tag is automatically applied to the variable or function. -Wabi-tag also warns about this situation; this warning can be avoided by explicitly tagging the variable or function or moving it into a tagged inline namespace.

init_priority (priority) ¶

In Standard C++, objects defined at namespace scope are guaranteed to be initialized in an order in strict accordance with that of their definitions_in a given translation unit_. No guarantee is made for initializations across translation units. However, GNU C++ allows you to control the order of initialization of objects defined at namespace scope with theinit_priority attribute by specifying a relative priority, with the same meaning as for the constructor attribute (see Common Function Attributes).

In the following example, A would normally be created beforeB, but the init_priority attribute reverses that order:

Some_Class A attribute ((init_priority (2000))); Some_Class B attribute ((init_priority (543)));

Note that the particular values of priority do not matter; only their relative ordering.

As with the priority argument to the constructor anddestructor attributes, a few targets do not support theinit_priority attribute. In that case the attribute is rejected with an error rather than ignored.

no_dangling ¶

This attribute can be applied on a class type, function, or member function. Dangling references to classes marked with this attribute will have the -Wdangling-reference diagnostic suppressed; so will references returned from the gnu::no_dangling-marked functions. For example:

class [[gnu::no_dangling]] S { … };

Or:

class A { int *p; [[gnu::no_dangling]] int &foo() { return *p; } };

[[gnu::no_dangling]] const int & foo (const int &i) { … }

This attribute takes an optional argument, which must be an expression that evaluates to true or false:

template struct [[gnu::no_dangling(std::is_reference_v)]] S { … };

Or:

template [[gnu::no_dangling(std::is_lvalue_reference_v)]] decltype(auto) foo(T&& t) { … };

warn_unused ¶

For C++ types with non-trivial constructors and/or destructors it is impossible for the compiler to determine whether a variable of this type is truly unused if it is not referenced. This type attribute informs the compiler that variables of this type should be warned about if they appear to be unused, just like variables of fundamental types.

This attribute is appropriate for types which just represent a value, such as std::string; it is not appropriate for types which control a resource, such as std::lock_guard.

This attribute is also accepted in C, but it is unnecessary because C does not have constructors or destructors.

cold ¶

In addition to functions and labels, GNU C++ allows the coldattribute to be used on C++ classes, structs, or unions. Applying the cold attribute on a type has the effect of treating every member function of the type, including implicit special member functions, as cold. If a member function is marked with thehot function attribute, the hot attribute takes precedence and the cold attribute is not propagated.

For the effects of the cold attribute on functions, seeCommon Function Attributes.

hot ¶

In addition to functions and labels, GNU C++ allows the hotattribute to be used on C++ classes, structs, or unions. Applying the hot attribute on a type has the effect of treating every member function of the type, including implicit special member functions, as hot. If a member function is marked with thecold function attribute, the cold attribute takes precedence and the hot attribute is not propagated.

For the effects of the hot attribute on functions, seeCommon Function Attributes.