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.
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.
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
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,
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.