gxxint.texi

gcc-2.95.3 Linux下最常用的C编译器

DECL_CONTEXT (B::f) == A
DECL_CLASS_CONTEXT (B::f) == B
@end example

Has values of:

	RECORD_TYPEs, or UNION_TYPEs

What things can this be used on:

	TYPE_DECLs, _DECLs


@item DECL_CONTEXT
Identifies the context that the _DECL was found in.  Can be used on
virtual function tables to find the type associated with the virtual
function table, but since they are FIELD_DECLs, DECL_FIELD_CONTEXT is a
better access method.  Internally the same as DECL_FIELD_CONTEXT, so
don't us both.  See also DECL_FIELD_CONTEXT, DECL_FCONTEXT and
DECL_CLASS_CONTEXT.

Has values of:

	RECORD_TYPEs


What things can this be used on:

@display
VAR_DECLs that are virtual function tables
_DECLs
@end display


@item DECL_FIELD_CONTEXT
Identifies the context that the FIELD_DECL was found in.  Internally the
same as DECL_CONTEXT, so don't us both.  See also DECL_CONTEXT,
DECL_FCONTEXT and DECL_CLASS_CONTEXT.

Has values of:

	RECORD_TYPEs

What things can this be used on:

@display
FIELD_DECLs that are virtual function pointers
FIELD_DECLs
@end display


@item DECL_NAME

Has values of:

@display
0 for things that don't have names
IDENTIFIER_NODEs for TYPE_DECLs
@end display

@item DECL_IGNORED_P
A bit that can be set to inform the debug information output routines in
the back-end that a certain _DECL node should be totally ignored.

Used in cases where it is known that the debugging information will be
output in another file, or where a sub-type is known not to be needed
because the enclosing type is not needed.

A compiler constructed virtual destructor in derived classes that do not
define an explicit destructor that was defined explicit in a base class
has this bit set as well.  Also used on __FUNCTION__ and
__PRETTY_FUNCTION__ to mark they are ``compiler generated.''  c-decl and
c-lex.c both want DECL_IGNORED_P set for ``internally generated vars,''
and ``user-invisible variable.''

Functions built by the C++ front-end such as default destructors,
virtual destructors and default constructors want to be marked that
they are compiler generated, but unsure why.

Currently, it is used in an absolute way in the C++ front-end, as an
optimization, to tell the debug information output routines to not
generate debugging information that will be output by another separately
compiled file.


@item DECL_VIRTUAL_P
A flag used on FIELD_DECLs and VAR_DECLs.  (Documentation in tree.h is
wrong.)  Used in VAR_DECLs to indicate that the variable is a vtable.
It is also used in FIELD_DECLs for vtable pointers.

What things can this be used on:

	FIELD_DECLs and VAR_DECLs


@item DECL_VPARENT
Used to point to the parent type of the vtable if there is one, else it
is just the type associated with the vtable.  Because of the sharing of
virtual function tables that goes on, this slot is not very useful, and
is in fact, not used in the compiler at all.  It can be removed.

What things can this be used on:

	VAR_DECLs that are virtual function tables

Has values of:

	RECORD_TYPEs maybe UNION_TYPEs


@item DECL_FCONTEXT
Used to find the first baseclass in which this FIELD_DECL is defined.
See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_CLASS_CONTEXT.

How it is used:

	Used when writing out debugging information about vfield and
	vbase decls.

What things can this be used on:

	FIELD_DECLs that are virtual function pointers
	FIELD_DECLs


@item DECL_REFERENCE_SLOT
Used to hold the initialize for the reference.

What things can this be used on:

	PARM_DECLs and VAR_DECLs that have a reference type


@item DECL_VINDEX
Used for FUNCTION_DECLs in two different ways.  Before the structure
containing the FUNCTION_DECL is laid out, DECL_VINDEX may point to a
FUNCTION_DECL in a base class which is the FUNCTION_DECL which this
FUNCTION_DECL will replace as a virtual function.  When the class is
laid out, this pointer is changed to an INTEGER_CST node which is
suitable to find an index into the virtual function table.  See
get_vtable_entry as to how one can find the right index into the virtual
function table.  The first index 0, of a virtual function table it not
used in the normal way, so the first real index is 1.

DECL_VINDEX may be a TREE_LIST, that would seem to be a list of
overridden FUNCTION_DECLs.  add_virtual_function has code to deal with
this when it uses the variable base_fndecl_list, but it would seem that
somehow, it is possible for the TREE_LIST to pursist until method_call,
and it should not.


What things can this be used on:

	FUNCTION_DECLs


@item DECL_SOURCE_FILE
Identifies what source file a particular declaration was found in.

Has values of:

	"<built-in>" on TYPE_DECLs to mean the typedef is built in


@item DECL_SOURCE_LINE
Identifies what source line number in the source file the declaration
was found at.

Has values of:

@display
0 for an undefined label

0 for TYPE_DECLs that are internally generated

0 for FUNCTION_DECLs for functions generated by the compiler
	(not yet, but should be)

0 for ``magic'' arguments to functions, that the user has no
	control over
@end display


@item TREE_USED

Has values of:

	0 for unused labels


@item TREE_ADDRESSABLE
A flag that is set for any type that has a constructor.


@item TREE_COMPLEXITY
They seem a kludge way to track recursion, poping, and pushing.  They only
appear in cp-decl.c and cp-decl2.c, so the are a good candidate for
proper fixing, and removal.


@item TREE_HAS_CONSTRUCTOR
A flag to indicate when a CALL_EXPR represents a call to a constructor.
If set, we know that the type of the object, is the complete type of the
object, and that the value returned is nonnull.  When used in this
fashion, it is an optimization.  Can also be used on SAVE_EXPRs to
indicate when they are of fixed type and nonnull.  Can also be used on
INDIRECT_EXPRs on CALL_EXPRs that represent a call to a constructor.


@item TREE_PRIVATE
Set for FIELD_DECLs by finish_struct.  But not uniformly set.

The following routines do something with PRIVATE access:
build_method_call, alter_access, finish_struct_methods,
finish_struct, convert_to_aggr, CWriteLanguageDecl, CWriteLanguageType,
CWriteUseObject, compute_access, lookup_field, dfs_pushdecl,
GNU_xref_member, dbxout_type_fields, dbxout_type_method_1


@item TREE_PROTECTED
The following routines do something with PROTECTED access:
build_method_call, alter_access, finish_struct, convert_to_aggr,
CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject,
compute_access, lookup_field, GNU_xref_member, dbxout_type_fields,
dbxout_type_method_1


@item TYPE_BINFO
Used to get the binfo for the type.

Has values of:

	TREE_VECs that are binfos

What things can this be used on:

	RECORD_TYPEs


@item TYPE_BINFO_BASETYPES
See also BINFO_BASETYPES.

@item TYPE_BINFO_VIRTUALS
A unique list of functions for the virtual function table.  See also
BINFO_VIRTUALS.

What things can this be used on:

	RECORD_TYPEs


@item TYPE_BINFO_VTABLE
Points to the virtual function table associated with the given type.
See also BINFO_VTABLE.

What things can this be used on:

	RECORD_TYPEs

Has values of:

	VAR_DECLs that are virtual function tables


@item TYPE_NAME
Names the type.

Has values of:

@display
0 for things that don't have names.
should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and 
        ENUM_TYPEs.
TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but 
        shouldn't be.
TYPE_DECL for typedefs, unsure why.
@end display

What things can one use this on:

@display
TYPE_DECLs
RECORD_TYPEs
UNION_TYPEs
ENUM_TYPEs
@end display

History:

	It currently points to the TYPE_DECL for RECORD_TYPEs,
	UNION_TYPEs and ENUM_TYPEs, but it should be history soon.


@item TYPE_METHODS
Synonym for @code{CLASSTYPE_METHOD_VEC}.  Chained together with
@code{TREE_CHAIN}.  @file{dbxout.c} uses this to get at the methods of a
class.


@item TYPE_DECL
Used to represent typedefs, and used to represent bindings layers.

Components:

	DECL_NAME is the name of the typedef.  For example, foo would
	be found in the DECL_NAME slot when @code{typedef int foo;} is
	seen.

	DECL_SOURCE_LINE identifies what source line number in the
	source file the declaration was found at.  A value of 0
	indicates that this TYPE_DECL is just an internal binding layer
	marker, and does not correspond to a user supplied typedef.

	DECL_SOURCE_FILE

@item TYPE_FIELDS
A linked list (via @code{TREE_CHAIN}) of member types of a class.  The
list can contain @code{TYPE_DECL}s, but there can also be other things
in the list apparently.  See also @code{CLASSTYPE_TAGS}.


@item TYPE_VIRTUAL_P
A flag used on a @code{FIELD_DECL} or a @code{VAR_DECL}, indicates it is
a virtual function table or a pointer to one.  When used on a
@code{FUNCTION_DECL}, indicates that it is a virtual function.  When
used on an @code{IDENTIFIER_NODE}, indicates that a function with this
same name exists and has been declared virtual.

When used on types, it indicates that the type has virtual functions, or
is derived from one that does.

Not sure if the above about virtual function tables is still true.  See
also info on @code{DECL_VIRTUAL_P}.

What things can this be used on:

	FIELD_DECLs, VAR_DECLs, FUNCTION_DECLs, IDENTIFIER_NODEs


@item VF_BASETYPE_VALUE
Get the associated type from the binfo that caused the given vfield to
exist.  This is the least derived class (the most parent class) that
needed a virtual function table.  It is probably the case that all uses
of this field are misguided, but they need to be examined on a
case-by-case basis.  See history for more information on why the
previous statement was made.

Set at @code{finish_base_struct} time.

What things can this be used on:

	TREE_LISTs that are vfields

History:

	This field was used to determine if a virtual function table's
	slot should be filled in with a certain virtual function, by
	checking to see if the type returned by VF_BASETYPE_VALUE was a
	parent of the context in which the old virtual function existed.
	This incorrectly assumes that a given type _could_ not appear as
	a parent twice in a given inheritance lattice.  For single
	inheritance, this would in fact work, because a type could not
	possibly appear more than once in an inheritance lattice, but
	with multiple inheritance, a type can appear more than once.


@item VF_BINFO_VALUE
Identifies the binfo that caused this vfield to exist.  If this vfield
is from the first direct base class that has a virtual function table,
then VF_BINFO_VALUE is NULL_TREE, otherwise it will be the binfo of the
direct base where the vfield came from.  Can use @code{TREE_VIA_VIRTUAL}
on result to find out if it is a virtual base class.  Related to the
binfo found by

@example