gxxint.texi

gcc库的原代码,对编程有很大帮助.

@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
get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)
@end example

@noindent
where @samp{t} is the type that has the given vfield.

@example
get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)
@end example

@noindent
will return the binfo for the the given vfield.

May or may not be set at @code{modify_vtable_entries} time.  Set at
@code{finish_base_struct} time.

What things can this be used on:

	TREE_LISTs that are vfields


@item VF_DERIVED_VALUE
Identifies the type of the most derived class of the vfield, excluding
the the class this vfield is for.

Set at @code{finish_base_struct} time.

What things can this be used on:

	TREE_LISTs that are vfields


@item VF_NORMAL_VALUE
Identifies the type of the most derived class of the vfield, including
the class this vfield is for.

Set at @code{finish_base_struct} time.

What things can this be used on:

	TREE_LISTs that are vfields


@item WRITABLE_VTABLES
This is a option that can be defined when building the compiler, that
will cause the compiler to output vtables into the data segment so that
the vtables maybe written.  This is undefined by default, because
normally the vtables should be unwritable.  People that implement object
I/O facilities may, or people that want to change the dynamic type of
objects may want to have the vtables writable.  Another way of achieving
this would be to make a copy of the vtable into writable memory, but the
drawback there is that that method only changes the type for one object.

@end table

@node Typical Behavior, Coding Conventions, Macros, Top
@section Typical Behavior

@cindex parse errors

Whenever seemingly normal code fails with errors like
@code{syntax error at `\@{'}, it's highly likely that grokdeclarator is
returning a NULL_TREE for whatever reason.

@node Coding Conventions, Templates, Typical Behavior, Top
@section Coding Conventions

It should never be that case that trees are modified in-place by the
back-end, @emph{unless} it is guaranteed that the semantics are the same
no matter how shared the tree structure is.  @file{fold-const.c} still
has some cases where this is not true, but rms hypothesizes that this
will never be a problem.

@node Templates, Access Control, Coding Conventions, Top
@section Templates

A template is represented by a @code{TEMPLATE_DECL}.  The specific
fields used are:

@table @code
@item DECL_TEMPLATE_RESULT
The generic decl on which instantiations are based.  This looks just
like any other decl.

@item DECL_TEMPLATE_PARMS
The parameters to this template.
@end table

The generic decl is parsed as much like any other decl as possible,
given the parameterization.  The template decl is not built up until the
generic decl has been completed.  For template classes, a template decl
is generated for each member function and static data member, as well.

Template members of template classes are represented by a TEMPLATE_DECL
for the class' parameters around another TEMPLATE_DECL for the member's
parameters.

All declarations that are instantiations or specializations of templates
refer to their template and parameters through DECL_TEMPLATE_INFO.

How should I handle parsing member functions with the proper param
decls?  Set them up again or try to use the same ones?  Currently we do
the former.  We can probably do this without any extra machinery in
store_pending_inline, by deducing the parameters from the decl in
do_pending_inlines.  PRE_PARSED_TEMPLATE_DECL?

If a base is a parm, we can't check anything about it.  If a base is not
a parm, we need to check it for name binding.  Do finish_base_struct if
no bases are parameterized (only if none, including indirect, are
parms).  Nah, don't bother trying to do any of this until instantiation
-- we only need to do name binding in advance.

Always set up method vec and fields, inc. synthesized methods.  Really?
We can't know the types of the copy folks, or whether we need a
destructor, or can have a default ctor, until we know our bases and
fields.  Otherwise, we can assume and fix ourselves later.  Hopefully.

@node Access Control, Error Reporting, Templates, Top
@section Access Control
The function compute_access returns one of three values:

@table @code
@item access_public
means that the field can be accessed by the current lexical scope.

@item access_protected
means that the field cannot be accessed by the current lexical scope
because it is protected.

@item access_private
means that the field cannot be accessed by the current lexical scope
because it is private.
@end table

DECL_ACCESS is used for access declarations; alter_access creates a list
of types and accesses for a given decl.

Formerly, DECL_@{PUBLIC,PROTECTED,PRIVATE@} corresponded to the return
codes of compute_access and were used as a cache for compute_access.
Now they are not used at all.

TREE_PROTECTED and TREE_PRIVATE are used to record the access levels
granted by the containing class.  BEWARE: TREE_PUBLIC means something
completely unrelated to access control!

@node Error Reporting, Parser, Access Control, Top
@section Error Reporting

The C++ front-end uses a call-back mechanism to allow functions to print
out reasonable strings for types and functions without putting extra
logic in the functions where errors are found.  The interface is through
the @code{cp_error} function (or @code{cp_warning}, etc.).  The
syntax is exactly like that of @code{error}, except that a few more
conversions are supported:

@itemize @bullet
@item
%C indicates a value of `enum tree_code'.
@item
%D indicates a *_DECL node.
@item
%E indicates a *_EXPR node.
@item
%L indicates a value of `enum languages'.
@item
%P indicates the name of a parameter (i.e. "this", "1", "2", ...)
@item
%T indicates a *_TYPE node.
@item
%O indicates the name of an operator (MODIFY_EXPR -> "operator =").

@end itemize

There is some overlap between these; for instance, any of the node
options can be used for printing an identifier (though only @code{%D}
tries to decipher function names).

For a more verbose message (@code{class foo} as opposed to just @code{foo},
including the return type for functions), use @code{%#c}.
To have the line number on the error message indicate the line of the
DECL, use @code{cp_error_at} and its ilk; to indicate which argument you want,
use @code{%+D}, or it will default to the first.

@node Parser, Copying Objects, Error Reporting, Top
@section Parser

Some comments on the parser:

The @code{after_type_declarator} / @code{notype_declarator} hack is
necessary in order to allow redeclarations of @code{TYPENAME}s, for
instance

@example
typedef int foo;
class A @{
  char *foo;
@};
@end example

In the above, the first @code{foo} is parsed as a @code{notype_declarator},
and the second as a @code{after_type_declarator}.

Ambiguities:

There are currently four reduce/reduce ambiguities in the parser.  They are:

1) Between @code{template_parm} and
@code{named_class_head_sans_basetype}, for the tokens @code{aggr
identifier}.  This situation occurs in code looking like

@example
template <class T> class A @{ @};
@end example

It is ambiguous whether @code{class T} should be parsed as the
declaration of a template type parameter named @code{T} or an unnamed
constant parameter of type @code{class T}.  Section 14.6, paragraph 3 of
the January '94 working paper states that the first interpretation is
the correct one.  This ambiguity results in two reduce/reduce conflicts.

2) Between @code{primary} and @code{type_id} for code like @samp{int()}
in places where both can be accepted, such as the argument to
@code{sizeof}.  Section 8.1 of the pre-San Diego working paper specifies
that these ambiguous constructs will be interpreted as @code{typename}s.
This ambiguity results in six reduce/reduce conflicts between
@samp{absdcl} and @samp{functional_cast}.

3) Between @code{functional_cast} and
@code{complex_direct_notype_declarator}, for various token strings.
This situation occurs in code looking like

@example
int (*a);
@end example

This code is ambiguous; it could be a declaration of the variable
@samp{a} as a pointer to @samp{int}, or it could be a functional cast of
@samp{*a} to @samp{int}.  Section 6.8 specifies that the former
interpretation is correct.  This ambiguity results in 7 reduce/reduce
conflicts.  Another aspect of this ambiguity is code like 'int (x[2]);',
which is resolved at the '[' and accounts for 6 reduce/reduce conflicts
between @samp{direct_notype_declarator} and
@samp{primary}/@samp{overqualified_id}.  Finally, there are 4 r/r
conflicts between @samp{expr_or_declarator} and @samp{primary} over code
like 'int (a);', which could probably be resolved but would also
probably be more trouble than it's worth.  In all, this situation
accounts for 17 conflicts.  Ack!

The second case above is responsible for the failure to parse 'LinppFile
ppfile (String (argv[1]), &outs, argc, argv);' (from Rogue Wave
Math.h++) as an object declaration, and must be fixed so that it does
not resolve until later.

4) Indirectly between @code{after_type_declarator} and @code{parm}, for
type names.  This occurs in (as one example) code like

@example
typedef int foo, bar;
class A @{
  foo (bar);
@};
@end example

What is @code{bar} inside the class definition?  We currently interpret
it as a @code{parm}, as does Cfront, but IBM xlC interprets it as an
@code{after_type_declarator}.  I believe that xlC is correct, in light
of 7.1p2, which says "The longest sequence of @i{decl-specifiers} that
could possibly be a type name is taken as the @i{decl-specifier-seq} of
a @i{declaration}."  However, it seems clear that this rule must be
violated in the case of constructors.  This ambiguity accounts for 8
conflicts.

Unlike the others, this ambiguity is not recognized by the Working Paper.

@node  Copying Objects, Exception Handling, Parser, Top
@section Copying Objects

The generated copy assignment operator in g++ does not currently do the
right thing for multiple inheritance involving virtual bases; it just
calls the copy assignment operators for its direct bases.  What it
should probably do is:

1) Split up the copy assignment operator for all classes that have
vbases into "copy my vbases" and "copy everything else" parts.  Or do
the trickiness that the constructors do to ensure that vbases don't get
initialized by intermediate bases.

2) Wander through the class lattice, find all vbases for which no
intermediate base has a user-defined copy assignment operator, and call
their "copy everything else" routines.  If not all of my vbases satisfy
this criterion, warn, because this may be surprising behavior.

3) Call the "copy everything else" routine for my direct bases.

If we only have one direct base, we can just foist everything off onto
them.

This issue is currently under discussion in the core reflector
(2/28/94).

@node  Exception Handling, Free Store, Copying Objects, Top
@section Exception Handling

Note, exception handling in g++ is still under development.  

This section describes the mapping of C++ exceptions in the C++
front-end, into the back-end exception handling framework.

The basic mechanism of exception handling in the back-end is
unwind-protect a la elisp.  This is a general, robust, and language
independent representation for exceptions.

The C++ front-end exceptions are mapping into the unwind-protect
semantics by the C++ front-end.  The mapping is describe below.

When -frtti is used, rtti is used to do exception object type checking,
when it isn't used, the encoded name for the type of the object being
thrown is used instead.  All code that originates exceptions, even code
that throws exceptions as a side effect, like dynamic casting, and all
code that catches exceptions must be compiled with either -frtti, or
-fno-rtti.  It is not possible to mix rtti base exception handling
objects with code that doesn't use rtti.  The exceptions to this, are
code that doesn't catch or throw exceptions, catch (...), and code that
just rethrows an exception.

Currently we use the normal mangling used in building functions names
(int's are "i", const char * is PCc) to build the non-rtti base type
descriptors for exception handling.  These descriptors are just plain
NULL terminated strings, and internally they are passed around as char
*.

In C++, all cleanups should be protected by exception regions.  The
region starts just after the reason why the cleanup is created has
ended.  For example, with an automatic variable, that has a constructor,
it would be right after the constructor is run.  The region ends just
before the finalization is expanded.  Since the backend may expand the
cleanup multiple times along different paths, once for normal end of the
region, once for non-local gotos, once for returns, etc, the backend
must take special care to protect the finalization expansion, if the
expansion is for any other reason than normal region end, and it is
`inline' (it is inside the exception region).  The backend can either