gxxint.texi

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

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 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 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, Exception Handling, 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  Exception Handling, Free Store, Parser, 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
choose to move them out of line, or it can created an exception region
over the finalization to protect it, and in the handler associated with
it, it would not run the finalization as it otherwise would have, but
rather just rethrow to the outer handler, careful to skip the normal
handler for the original region.

In Ada, they will use the more runtime intensive approach of having
fewer regions, but at the cost of additional work at run time, to keep a
list of things that need cleanups.  When a variable has finished
construction, they add the cleanup to the list, when the come to the end
of the lifetime of the variable, the run the list down.  If the take a
hit before the section finishes normally, they examine the list for
actions to perform.  I hope they add this logic into the back-end, as it
would be nice to get that alternative approach in C++.

On an rs6000, xlC stores exception objects on that stack, under the try
block.  When is unwinds down into a handler, the frame pointer is
adjusted back to the normal value for the frame in which the handler
resides, and the stack pointer is left unchanged from the time at which
the object was thrown.  This is so that there is always someplace for
the exception object, and nothing can overwrite it, once we start
throwing.  The only bad part, is that the stack remains large.

The below points out some things that work in g++'s exception handling.

All completely constructed temps and local variables are cleaned up in
all unwinded scopes.  Completely constructed parts of partially
constructed objects are cleaned up.  This includes partially built
arrays.  Exception specifications are now handled.  Thrown objects are
now cleaned up all the time.  We can now tell if we have an active
exception being thrown or not (__eh_type != 0).  We use this to call
terminate if someone does a throw; without there being an active
exception object.  uncaught_exception () works.  Exception handling
should work right if you optimize.  Exception handling should work with
-fpic or -fPIC.

The below points out some flaws in g++'s exception handling, as it now
stands.

Only exact type matching or reference matching of throw types works when
-fno-rtti is used.  Only works on a SPARC (like Suns) (both -mflat and
-mno-flat models work), SPARClite, Hitachi SH, i386, arm, rs6000,
PowerPC, Alpha, mips, VAX, m68k and z8k machines.  SPARC v9 may not
work.  HPPA is mostly done, but throwing between a shared library and
user code doesn't yet work.  Some targets have support for data-driven
unwinding.  Partial support is in for all other machines, but a stack
unwinder called __unwind_function has to be written, and added to
libgcc2 for them.  The new EH code doesn't rely upon the
__unwind_function for C++ code, instead it creates per function
unwinders right inside the function, unfortunately, on many platforms
the definition of RETURN_ADDR_RTX in the tm.h file for the machine port
is wrong.  See below for details on __unwind_function.  RTL_EXPRs for EH
cond variables for && and || exprs should probably be wrapped in
UNSAVE_EXPRs, and RTL_EXPRs tweaked so that they can be unsaved.

We only do pointer conversions on exception matching a la 15.3 p2 case
3: `A handler with type T, const T, T&, or const T& is a match for a
throw-expression with an object of type E if [3]T is a pointer type and
E is a pointer type that can be converted to T by a standard pointer
conversion (_conv.ptr_) not involving conversions to pointers to private
or protected base classes.' when -frtti is given.