gcc: C++ Attributes
1
1 7.7 C++-Specific Variable, Function, and Type Attributes
1 ========================================================
1
1 Some attributes only make sense for C++ programs.
1
1 'abi_tag ("TAG", ...)'
1 The 'abi_tag' attribute can be applied to a function, variable, or
1 class declaration. It modifies the mangled name of the entity to
1 incorporate the tag name, in order to distinguish the function or
1 class from an earlier version with a different ABI; perhaps the
1 class has changed size, or the function has a different return type
1 that is not encoded in the mangled name.
1
1 The attribute can also be applied to an inline namespace, but does
1 not affect the mangled name of the namespace; in this case it is
1 only used for '-Wabi-tag' warnings and automatic tagging of
1 functions and variables. Tagging inline namespaces is generally
1 preferable to tagging individual declarations, but the latter is
1 sometimes necessary, such as when only certain members of a class
1 need to be tagged.
1
1 The argument can be a list of strings of arbitrary length. The
1 strings are sorted on output, so the order of the list is
1 unimportant.
1
1 A redeclaration of an entity must not add new ABI tags, since doing
1 so would change the mangled name.
1
1 The ABI tags apply to a name, so all instantiations and
1 specializations of a template have the same tags. The attribute
1 will be ignored if applied to an explicit specialization or
1 instantiation.
1
1 The '-Wabi-tag' flag enables a warning about a class which does not
1 have all the ABI tags used by its subobjects and virtual functions;
1 for users with code that needs to coexist with an earlier ABI,
1 using this option can help to find all affected types that need to
1 be tagged.
1
1 When a type involving an ABI tag is used as the type of a variable
1 or return type of a function where that tag is not already present
1 in the signature of the function, the tag is automatically applied
1 to the variable or function. '-Wabi-tag' also warns about this
1 situation; this warning can be avoided by explicitly tagging the
1 variable or function or moving it into a tagged inline namespace.
1
1 'init_priority (PRIORITY)'
1
1 In Standard C++, objects defined at namespace scope are guaranteed
1 to be initialized in an order in strict accordance with that of
1 their definitions _in a given translation unit_. No guarantee is
1 made for initializations across translation units. However, GNU
1 C++ allows users to control the order of initialization of objects
1 defined at namespace scope with the 'init_priority' attribute by
1 specifying a relative PRIORITY, a constant integral expression
1 currently bounded between 101 and 65535 inclusive. Lower numbers
1 indicate a higher priority.
1
1 In the following example, 'A' would normally be created before 'B',
1 but the 'init_priority' attribute reverses that order:
1
1 Some_Class A __attribute__ ((init_priority (2000)));
1 Some_Class B __attribute__ ((init_priority (543)));
1
1 Note that the particular values of PRIORITY do not matter; only
1 their relative ordering.
1
1 'warn_unused'
1
1 For C++ types with non-trivial constructors and/or destructors it
1 is impossible for the compiler to determine whether a variable of
1 this type is truly unused if it is not referenced. This type
1 attribute informs the compiler that variables of this type should
1 be warned about if they appear to be unused, just like variables of
1 fundamental types.
1
1 This attribute is appropriate for types which just represent a
1 value, such as 'std::string'; it is not appropriate for types which
1 control a resource, such as 'std::lock_guard'.
1
1 This attribute is also accepted in C, but it is unnecessary because
1 C does not have constructors or destructors.
1