to that declaration (which may be nested in another declaration, for
example in the case of a parameter declaration). In future, attribute
specifiers in some places may however apply to a particular declarator
-within a declaration instead; these cases are noted below.
+within a declaration instead; these cases are noted below. Where an
+attribute specifier is applied to a parameter declared as a function or
+an array, it should apply to the function or array rather than the
+pointer to which the parameter is implicitly converted, but this is not
+yet correctly implemented.
Any list of specifiers and qualifiers at the start of a declaration may
contain attribute specifiers, whether or not such a list may in that
function or variable, this feature allows you to define names for the
linker that do not start with an underscore.
+It does not make sense to use this feature with a non-static local
+variable since such variables do not have assembler names. If you are
+trying to put the variable in a particular register, see @ref{Explicit
+Reg Vars}. GCC presently accepts such code with a warning, but will
+probably be changed to issue an error, rather than a warning, in the
+future.
+
You cannot use @code{asm} in this way in a function @emph{definition}; but
you can get the same effect by writing a declaration for the function
before its definition and putting @code{asm} there, like this:
* Min and Max:: C++ Minimum and maximum operators.
* Volatiles:: What constitutes an access to a volatile object.
* Restricted Pointers:: C99 restricted pointers and references.
+* Vague Linkage:: Where G++ puts inlines, vtables and such.
* C++ Interface:: You can use a single C++ header file for both
declarations and definitions.
* Template Instantiation:: Methods for ensuring that exactly one copy of
specify @code{__restrict__} in a function definition, rather than
in a function prototype as well.
+@node Vague Linkage
+@section Vague Linkage
+@cindex vague linkage
+
+There are several constructs in C++ which require space in the object
+file but are not clearly tied to a single translation unit. We say that
+these constructs have ``vague linkage''. Typically such constructs are
+emitted wherever they are needed, though sometimes we can be more
+clever.
+
+@table @asis
+@item Inline Functions
+Inline functions are typically defined in a header file which can be
+included in many different compilations. Hopefully they can usually be
+inlined, but sometimes an out-of-line copy is necessary, if the address
+of the function is taken or if inlining fails. In general, we emit an
+out-of-line copy in all translation units where one is needed. As an
+exception, we only emit inline virtual functions with the vtable, since
+it will always require a copy.
+
+Local static variables and string constants used in an inline function
+are also considered to have vague linkage, since they must be shared
+between all inlined and out-of-line instances of the function.
+
+@item VTables
+@cindex vtable
+C++ virtual functions are implemented in most compilers using a lookup
+table, known as a vtable. The vtable contains pointers to the virtual
+functions provided by a class, and each object of the class contains a
+pointer to its vtable (or vtables, in some multiple-inheritance
+situations). If the class declares any non-inline, non-pure virtual
+functions, the first one is chosen as the ``key method'' for the class,
+and the vtable is only emitted in the translation unit where the key
+method is defined.
+
+@emph{Note:} If the chosen key method is later defined as inline, the
+vtable will still be emitted in every translation unit which defines it.
+Make sure that any inline virtuals are declared inline in the class
+body, even if they are not defined there.
+
+@item type_info objects
+@cindex type_info
+@cindex RTTI
+C++ requires information about types to be written out in order to
+implement @samp{dynamic_cast}, @samp{typeid} and exception handling.
+For polymorphic classes (classes with virtual functions), the type_info
+object is written out along with the vtable so that @samp{dynamic_cast}
+can determine the dynamic type of a class object at runtime. For all
+other types, we write out the type_info object when it is used: when
+applying @samp{typeid} to an expression, throwing an object, or
+referring to a type in a catch clause or exception specification.
+
+@item Template Instantiations
+Most everything in this section also applies to template instantiations,
+but there are other options as well.
+@xref{Template Instantiation,,Where's the Template?}.
+
+@end table
+
+When used with GNU ld version 2.8 or later on an ELF system such as
+Linux/GNU or Solaris 2, or on Microsoft Windows, duplicate copies of
+these constructs will be discarded at link time. This is known as
+COMDAT support.
+
+On targets that don't support COMDAT, but do support weak symbols, GCC
+will use them. This way one copy will override all the others, but
+the unused copies will still take up space in the executable.
+
+For targets which do not support either COMDAT or weak symbols,
+most entities with vague linkage will be emitted as local symbols to
+avoid duplicate definition errors from the linker. This will not happen
+for local statics in inlines, however, as having multiple copies will
+almost certainly break things.
+
+@xref{C++ Interface,,Declarations and Definitions in One Header}, for
+another way to control placement of these constructs.
+
@node C++ Interface
@section Declarations and Definitions in One Header
Note that the particular values of @var{priority} do not matter; only their
relative ordering.
-
-@item com_interface
-@cindex com_interface attribute
-
-@c This is based on: 1) grepping the code,
-@c 2) http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg01212.html
-@c 3) http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg01215.html
-@c and 4) a lot of guesswork. You can tell I don't use COM. -pme 21Dec00
-
-This type attribute takes no parameters, and marks a class or struct as an
-interface for communication via COM; the class will support the COM ABI
-rather than the full C++ ABI. Currently this means that RTTI is not possible
-with the resulting class heirarchy. The virtual pointer table will be
-changed to be COM-compliant. Also, all classes and structs derived from one
-marked with this attribute are implicitly marked with the same attribute;
-thus, only the base class in a COM hierarchy needs @code{com_interface}.
-
@item java_interface
@cindex java_interface attribute
OSDN Git Service
