Some attributes only make sense for C++ programs.
abi_tagattribute can be applied to a function or class declaration. It modifies the mangled name of the function or class 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 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 a function or class 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.
-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.
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 users to control the order of initialization of objects defined at namespace scope with the
init_priority attribute by specifying a relative priority, a constant integral expression currently bounded between 101 and 65535 inclusive. Lower numbers indicate a higher priority.
In the following example,
A would normally be created before
B, 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.
extern "Java"block. Calls to methods declared in this interface are dispatched using GCJ's interface table mechanism, instead of regular virtual table dispatch.
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
This attribute is also accepted in C, but it is unnecessary because C does not have constructors or destructors.
See also Namespace Association.
© Free Software Foundation
Licensed under the GNU Free Documentation License, Version 1.3.