reno.texi

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

\input texinfo       @c                    -*- Texinfo -*-
@setfilename reno-1.info

@ifinfo
@format
START-INFO-DIR-ENTRY
* Reno 1: (reno-1).             The GNU C++ Renovation Project, Phase 1.
END-INFO-DIR-ENTRY
@end format
@end ifinfo

@ifinfo
Copyright @copyright{} 1992, 1993, 1994 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through TeX and print the
results, provided the printed document carries a copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).

@end ignore

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions.
@end ifinfo

@setchapternewpage odd
@settitle GNU C++ Renovation Project
@c @smallbook

@titlepage
@finalout
@title GNU C++ Renovation Project
@subtitle Phase 1.3
@author Brendan Kehoe, Jason Merrill,
@author Mike Stump, Michael Tiemann
@page

Edited March, 1994 by Roland Pesch (@code{pesch@@cygnus.com})
@vskip 0pt plus 1filll
Copyright @copyright{} 1992, 1993, 1994 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).
@end ignore

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions.
@end titlepage

@ifinfo
@node Top
@top @sc{gnu} C++ Renovation Project

This file describes the goals of the @sc{gnu} C++ Renovation Project,
and its accomplishments to date (as of Phase 1.3).

It also discusses the remaining divergences from @sc{gnu} C++, and how the
name encoding in @sc{gnu} C++ differs from the sample encoding in
@cite{The Annotated C++ Reference Manual}.
@c This is not a good place to introduce the acronym ARM because it's
@c info-only. 

@menu
* Introduction::	What is the GNU C++ Renovation Project?
* Changes::		Summary of changes since previous GNU C++ releases.
* Plans::		Plans for Reno-2.
* Templates::		The template implementation.
* ANSI::		GNU C++ conformance to ANSI C++.
* Encoding::		Name encoding in GNU C++.
@end menu

@end ifinfo

@node Introduction
@chapter Introduction

As you may remember, @sc{gnu} C++ was the first native-code C++
compiler available under Unix (December 1987).  In November 1988, it was
judged superior to the AT&T compiler in a Unix World review.  In 1990 it
won a Sun Observer ``Best-Of'' award.  But now, with new requirements
coming out of the @sc{ansi} C++ committee and a growing backlog of bugs, it's
clear that @sc{gnu} C++ needs an overhaul.

The C++ language has been under development since 1982.  It has
evolved significantly since its original incarnation (C with Classes),
addressing many commercial needs and incorporating many lessons
learned as more and more people started using ``object-oriented''
programming techniques.  In 1989, the first X3J16 committee meeting
was held in Washington DC; in the interest of users, C++ was going to
be standardized.

As C++ has become more popular, more demands have been placed on its
compilers.  Some compilers are up to the demands, others are not.
@sc{gnu} C++ was used to prototype several features which have since
been incorporated into the standard, most notably exception handling.
While @sc{gnu} C++ has been an excellent experimental vehicle, it did
not have the resources that AT&T, Borland, or Microsoft have at their
disposal.

We believe that @sc{gnu} C++ is an important compiler, providing users with
many of the features that have made @sc{gnu} C so popular: fast compilation,
good error messages, innovative features, and full sources that may be
freely redistributed.  The purpose of this overhaul, dubbed the @var{@sc{gnu}
C++ Renovation Project}, is to take advantage of the functionality that
@sc{gnu} C++ offers today, to strengthen its base technology, and put it in a
position to remain---as other @sc{gnu} software currently is---the technical
leader in the field.

This release represents the latest phase of work in strengthening the
compiler on a variety of points.  It includes many months of
work concentrated on fixing many of the more egregious bugs that
presented themselves in the compiler recently.
@ignore
@c FIXME-- update?
Nearly 85% of all bugs reported in the period of February to September
of 1992 were fixed as part of the work in the first phase.
@end ignore
In the coming months, we hope to continue expanding and enhancing the
quality and dependability of the industry's only freely redistributable
C++ compiler.

@node Changes
@chapter Changes in Behavior in @sc{gnu} C++

The @sc{gnu} C++ compiler continues to improve and change.  A major goal
of our work has been to continue to bring the compiler into compliance
with the draft @sc{ansi} C++ standard, and with @cite{The Annotated C++
Reference Manual} (the @sc{arm}).  This section outlines most of the
user-noticeable changes that might be encountered during the normal
course of use.

@menu
* Summary of Phase 1.3::
* Major changes::
* New features::
* Enhancements and bug fixes::
* Problems with debugging::
@end menu

@node Summary of Phase 1.3
@section Summary of Changes in Phase 1.3

The bulk of this note discusses the cumulative effects of the @sc{gnu} C++
Renovation Project to date.  The work during its most recent phase (1.3)
had these major effects:

@itemize @bullet
@item The standard compiler driver @code{g++} is now the faster compiled
version, rather than a shell script.

@item Nested types work much better; notably, nesting is no longer
restricted to nine levels.

@item Better @sc{arm} conformance on member access control.

@item The compiler now always generates default assignment operators
(@samp{operator =}), copy constructors (@samp{X::X(X&)}), and default
constructors (@samp{X::X()}) whenever they are required.

@item The new draft @sc{ansi} standard keyword @code{mutable} is supported.

@item @samp{-fansi-overloading} is the default, to comply better with
the @sc{arm} (at some cost in compatibility to earlier versions of @sc{gnu} C++).

@item More informative error messages.

@item System include files are automatically treated as if they were
wrapped in @samp{extern "C" @{ @}}.

@item The new option @samp{-falt-external-templates} provides alternate
template instantiation semantics.

@item Operator declarations are now checked more strictly.

@item You can now use template type arguments in the template parameter list.

@item You can call the destructor for any type.

@item The compiler source code is better organized.

@item You can specify where to instantiate template definitions explicitly.
@end itemize

Much of the work in Phase 1.3 went to elimination of known bugs, as well
as the major items above.

During the span of Phase 1.3, there were also two changes associated
with the compiler that, while not specifically part of the C++
Renovation project, may be of interest:

@itemize @bullet
@item @code{gcov}, a code coverage tool for @sc{gnu cc}, is now available
from Cygnus Support.  (@code{gcov} is free software, but the @sc{fsf} has not
yet accepted it.)  @xref{Gcov,, @code{gcov}: a Test Coverage Program,
gcc.info, Using GNU CC}, for more information (in Cygnus releases of
that manual).

@item @sc{gnu} C++ now supports @dfn{signatures}, a language extension to
provide more flexibility in abstract type definitions.  @xref{C++
Signatures,, Type Abstraction using Signatures, gcc.info, Using GNU CC}.
@end itemize

@node Major changes
@section Major Changes

This release includes four wholesale rewrites of certain areas of
compiler functionality:

@enumerate 1
@item Argument matching.  @sc{gnu} C++ is more compliant with the rules
described in Chapter 13, ``Overloading'', of the @sc{arm}.  This behavior is
the default, though you can specify it explicitly with
@samp{-fansi-overloading}.   For compatibility with earlier releases of
@sc{gnu} C++, specify @samp{-fno-ansi-overloading}; this makes the compiler
behave as it used to with respect to argument matching and name overloading.

@item Default constructors/destructors.  Section 12.8 of the @sc{arm}, ``Copying
Class Objects'', and Section 12.1, ``Constructors'', state that a
compiler must declare such default functions if the user does not
specify them.  @sc{gnu} C++ now declares, and generates when necessary,
the defaults for constructors and destructors you might omit.  In
particular, assignment operators (@samp{operator =}) behave the same way
whether you define them, or whether the compiler generates them by
default; taking the address of the default @samp{operator =} is now
guaranteed to work.  Default copy constructors (@samp{X::X(X&)}) now
function correctly, rather than calling the copy assignment operator for
the base class.  Finally, constructors (@samp{X::X()}), as well as
assignment operators and copy constructors, are now available whenever
they are required.

@c XXX This may be taken out eventually...
@item Binary incompatibility.  There are no new binary incompatibilities
in Phase 1.3, but Phase 1.2 introduced two binary incompatibilities with
earlier releases.  First, the functionality of @samp{operator
new} and @samp{operator delete} changed.  Name encoding
(``mangling'') of virtual table names changed as well.  Libraries
built with versions of the compiler earlier than Phase 1.2 must be
compiled with the new compiler.  (This includes the Cygnus Q2
progressive release and the FSF 2.4.5 release.)

@item New @code{g++} driver.
A new binary @code{g++} compiler driver replaces the shell script.
The new driver executes faster.
@end enumerate

@node New features
@section New features

@itemize @bullet
@item
The compiler warns when a class contains only private constructors
or destructors, and has no friends.  At the request of some of our
customers, we have added a new option, @samp{-Wctor-dtor-privacy} (on by
default), and its negation, @samp{-Wno-ctor-dtor-privacy}, to control
the emission of this warning.  If, for example, you are working towards
making your code compile warning-free, you can use @w{@samp{-Wall
-Wno-ctor-dtor-privacy}} to find the most common warnings.

@item
There is now a mechanism which controls exactly when templates are
expanded, so that you can reduce memory usage and program size and also
instantiate them exactly once.  You can control this mechanism with the
option @samp{-fexternal-templates} and its corresponding negation
@samp{-fno-external-templates}.  Without this feature, space consumed by
template instantiations can grow unacceptably in large-scale projects
with many different source files.  The default is
@samp{-fno-external-templates}.

You do not need to use the @samp{-fexternal-templates} option when
compiling a file that does not define and instantiate templates used in
other files, even if those files @emph{are} compiled with
@samp{-fexternal-templates}.  The only side effect is an increase in
object size for each file that was compiled without
@samp{-fexternal-templates}.

When your code is compiled with @samp{-fexternal-templates}, all
template instantiations are external; this requires that the templates
be under the control of @samp{#pragma interface} and @samp{#pragma
implementation}.  All instantiations that will be needed should be in
the implementation file; you can do this with a @code{typedef} that
references the instantiation needed.  Conversely, when you compile using
the option @samp{-fno-external-templates}, all template instantiations are
explicitly internal.

@samp{-fexternal-templates} also allows you to finally separate class
template function definitions from their declarations, thus speeding up
compilation times for every file that includes the template declaration.
Now you can have tens or even hundreds of lines in template
declarations, and thousands or tens of thousands of lines in template
definitions, with the definitions only going through the compiler once
instead of once for each source file.  It is important to note that you
must remember to externally instantiate @emph{all} templates that are
used from template declarations in interface files.  If you forget to do
this, unresolved externals will occur.

In the example below, the object file generated (@file{example.o}) will
contain the global instantiation for @samp{Stack<int>}.  If other types
of @samp{Stack} are needed, they can be added to @file{example.cc} or
placed in a new file, in the same spirit as @file{example.cc}.

@code{foo.h}:
@smallexample
@group
#pragma interface "foo.h"
template<class T>
class Stack @{
  static int statc;
  static T statc2;
  Stack() @{ @}
  virtual ~Stack() @{ @}
  int bar();
@};
@end group
@end smallexample

@code{example.cc}:
@smallexample
@group
#pragma implementation "foo.h"
#include "foo.h"

typedef Stack<int> t;
int Stack<int>::statc;
int Stack<int>::statc2;
int Stack<int>::bar() @{ @}
@end group
@end smallexample

Note that using @samp{-fexternal-templates} does not reduce memory usage
from completely different instantiations (@samp{Stack<Name>} vs.
@samp{Stack<Net_Connection>}), but only collapses different occurrences
of @samp{Stack<Name>} so that only one @samp{Stack<Name>} is generated.

@samp{-falt-external-templates} selects a slight variation in the
semantics described above (incidentally, you need not specify both
options; @samp{-falt-external-templates} implies
@samp{-fexternal-templates}).  

With @samp{-fexternal-templates}, the compiler emits a definition in the
implementation file that includes the header definition, @emph{even if}
instantiation is triggered from a @emph{different} implementation file
(e.g. with a template that uses another template).

With @samp{-falt-external-templates}, the definition always goes in the
implementation file that triggers instantiation.

For instance, with these two header files---

@example
@exdent @file{a.h}:
#pragma interface
template <class T> class A @{ @dots{} @};

@exdent @file{b.h}:
#pragma interface