diff options
Diffstat (limited to 'contrib/gcc/cp/reno.texi')
| -rw-r--r-- | contrib/gcc/cp/reno.texi | 752 |
1 files changed, 0 insertions, 752 deletions
diff --git a/contrib/gcc/cp/reno.texi b/contrib/gcc/cp/reno.texi deleted file mode 100644 index 59c3448..0000000 --- a/contrib/gcc/cp/reno.texi +++ /dev/null @@ -1,752 +0,0 @@ -\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 -class B @{ @dots{} @}; -void f (A<B>); -@end example - -Under @samp{-fexternal-templates}, the definition of @samp{A<B>} ends up -in the implementation file that includes @file{a.h}. Under -@samp{-falt-external-templates}, the same definition ends up in the -implementation file that includes @file{b.h}. - -@item -You can control explicitly where a template is instantiated, without -having to @emph{use} the template to get an instantiation. - -To instantiate a class template explicitly, write @samp{template -class @var{name}<paramvals>}, where @var{paramvals} is a list of values -for the template parameters. For example, you might write - -@example -template class A<int> -@end example - -Similarly, to instantiate a function template explicitly, write -@samp{template @var{fnsign}} where @var{fnsign} is the particular -function signature you need. For example, you might write - -@example -template void foo (int, int) -@end example - -This syntax for explicit template instantiation agrees with recent -extensions to the draft @sc{ansi} standard. - -@item -The compiler's actions on @sc{ansi}-related warnings and errors have -been further enhanced. The @samp{-pedantic-errors} option produces -error messages in a number of new situations: using @code{return} in a -non-@code{void} function (one returning a value); declaring a local -variable that shadows a parameter (e.g., the function takes an argument -@samp{a}, and has a local variable @samp{a}); and use of the @samp{asm} -keyword. Finally, the compiler by default now issues a warning when -converting from an @code{int} to an enumerated type. This is likely to -cause many new warnings in code that hadn't triggered them before. For -example, when you compile this code, - -@smallexample -@group -enum boolean @{ false, true @}; -void -f () -@{ - boolean x; - - x = 1; //@i{assigning an @code{int} to an @code{enum} now triggers a warning} -@} -@end group -@end smallexample - -@noindent -you should see the warning ``@code{anachronistic conversion from integer -type to enumeral type `boolean'}''. Instead of assigning the value 1, -assign the original enumerated value @samp{true}. -@end itemize - -@node Enhancements and bug fixes -@section Enhancements and bug fixes - -@itemize @bullet -@cindex nested types in template parameters -@item -You can now use nested types in a template parameter list, even if the nested -type is defined within the same class that attempts to use the template. -For example, given a template @code{list}, the following now works: - -@smallexample -struct glyph @{ - @dots{} - struct stroke @{ @dots{} @}; - list<stroke> l; - @dots{} -@} -@end smallexample - -@cindex function pointers vs template parameters -@item -Function pointers now work in template parameter lists. For -example, you might want to instantiate a parameterized @code{list} class -in terms of a pointer to a function like this: - -@smallexample -list<int (*)(int, void *)> fnlist; -@end smallexample - -@item -@c FIXME! Really no limit? Jason said "deeper than 9" now OK... -Nested types are now handled correctly. In particular, there is no -longer a limit to how deeply you can nest type definitions. - -@item -@sc{gnu} C++ now conforms to the specifications in Chapter 11 of the -@sc{arm}, ``Member Access Control''. - -@item -The @sc{ansi} C++ committee has introduced a new keyword @code{mutable}. -@sc{gnu} C++ supports it. Use @code{mutable} to specify that some -particular members of a @code{const} class are @emph{not} constant. For -example, you can use this to include a cache in a data structure that -otherwise represents a read-only database. - -@item -Error messages now explicitly specify the declaration, type, or -expression that contains an error. - -@item -To avoid copying and editing all system include files during @sc{gnu} -C++ installation, the compiler now automatically recognizes system -include files as C language definitions, as if they were wrapped in -@samp{extern "C" @{ @dots{} @}}. - -@item -The compiler checks operator declarations more strictly. For example, -you may no longer declare an @samp{operator +} with three arguments. - -@item -You can now use template type arguments in the same template -parameter list where the type argument is specified (as well as in the -template body). For example, you may write - -@example -template <class T, T t> class A @{ @dots{} @}; -@end example - -@item -Destructors are now available for all types, even built-in ones; for -example, you can call @samp{int::~int}. (Destructors for types like -@code{int} do not actually do anything, but their existence provides a -level of generality that permits smooth template expansion in more -cases.) - -@item -Enumerated types declared inside a class are now handled correctly. - -@item -An argument list for a function may not use an initializer list for its default -value. For example, @w{@samp{void foo ( T x = @{ 1, 2 @} )}} is not permitted. - -@item -A significant amount of work went into improving the ability of the -compiler to act accurately on multiple inheritance and virtual -functions. Virtual function dispatch has been enhanced as well. - -@item -The warning concerning a virtual inheritance environment with a -non-virtual destructor has been disabled, since it is not clear that -such a warning is warranted. - -@item -Until exception handling is fully implemented in the Reno-2 release, use -of the identifiers @samp{catch}, @samp{throw}, or @samp{try} results -in the warning: - -@smallexample -t.C:1: warning: `catch', `throw', and `try' - are all C++ reserved words -@end smallexample - -@item -When giving a warning or error concerning initialization of a member in a -class, the compiler gives the name of the member if it has one. - -@item -Detecting friendship between classes is more accurately checked. - -@item -The syntaxes of @w{@samp{#pragma implementation "file.h"}} and -@samp{#pragma interface} are now more strictly controlled. The compiler -notices (and warns) when any text follows @file{file.h} in the -implementation pragma, or follows the word @samp{interface}. Any such -text is otherwise ignored. - -@item -Trying to declare a template on a variable or type is now considered an -error, not an unimplemented feature. - -@item -When an error occurs involving a template, the compiler attempts to -tell you at which point of instantiation the error occurred, in -addition to noting the line in the template declaration which had the -actual error. - -@item -The symbol names for function templates in the resulting assembly file -are now encoded according to the arguments, rather than just being -emitted as, for example, two definitions of a function @samp{foo}. - -@item -Template member functions that are declared @code{static} no longer -receive a @code{this} pointer. - -@item -Case labels are no longer allowed to have commas to make up their -expressions. - -@item -Warnings concerning the shift count of a left or right shift now tell -you if it was a @samp{left} or @samp{right} shift. - -@item -The compiler now warns when a decimal constant is so large that it -becomes @code{unsigned}. - -@item -Union initializers which are raw constructors are now handled properly. - -@item -The compiler no longer gives incorrect errors when initializing a -union with an empty initializer list. - -@item -Anonymous unions are now correctly used when nested inside a class. - -@item -Anonymous unions declared as static class members are now handled -properly. - -@item -The compiler now notices when a field in a class is declared both as -a type and a non-type. - -@item -The compiler now warns when a user-defined function shadows a -built-in function, rather than emitting an error. - -@item -A conflict between two function declarations now produces an error -regardless of their language context. - -@item -Duplicate definitions of variables with @samp{extern "C"} linkage are no -longer considered in error. (Note in C++ linkage---the default---you may -not have more than one definition of a variable.) - -@item -Referencing a label that is not defined in any function is now an error. - -@item -The syntax for pointers to methods has been improved; there are still -some minor bugs, but a number of cases should now be accepted by the -compiler. - -@item -In error messages, arguments are now numbered starting at 1, instead of -0. Therefore, in the function @samp{void foo (int a, int b)}, the -argument @samp{a} is argument 1, and @samp{b} is argument 2. There is -no longer an argument 0. - -@item -The tag for an enumerator, rather than its value, used as a default -argument is now shown in all error messages. For example, @w{@samp{void -foo (enum x (= true))}} is shown instead of @w{@samp{void foo (enum x (= -1))}}. - -@item -The @samp{__asm__} keyword is now accepted by the C++ front-end. - -@item -Expressions of the form @samp{foo->~Class()} are now handled properly. - -@item -The compiler now gives better warnings for situations which result in -integer overflows (e.g., in storage sizes, enumerators, unary -expressions, etc). - -@item -@code{unsigned} bitfields are now promoted to @code{signed int} if the -field isn't as wide as an @code{int}. - -@item -Declaration and usage of prefix and postfix @samp{operator ++} and -@samp{operator --} are now handled correctly. For example, - -@smallexample -@group -class foo -@{ -public: - operator ++ (); - operator ++ (int); - operator -- (); - operator -- (int); -@}; - -void -f (foo *f) -@{ - f++; // @i{call @code{f->operator++(int)}} - ++f; // @i{call @code{f->operator++()}} - f--; // @i{call @code{f->operator++(int)}} - --f; // @i{call @code{f->operator++()}} -@} -@end group -@end smallexample - -@item -In accordance with @sc{arm} section 10.1.1, ambiguities and dominance are now -handled properly. The rules described in section 10.1.1 are now fully -implemented. - -@end itemize - -@node Problems with debugging -@section Problems with debugging - -Two problems remain with regard to debugging: - -@itemize @bullet -@item -Debugging of anonymous structures on the IBM RS/6000 host is incorrect. - -@item -Symbol table size is overly large due to redundant symbol information; -this can make @code{gdb} coredump under certain circumstances. This -problem is not host-specific. -@end itemize - -@node Plans -@chapter Plans for Reno-2 - -The overall goal for the second phase of the @sc{gnu} C++ Renovation -Project is to bring @sc{gnu} C++ to a new level of reliability, quality, -and competitiveness. As particular elements of this strategy, we intend -to: - -@enumerate 0 -@item -Fully implement @sc{ansi} exception handling. - -@item -With the exception handling, add Runtime Type Identification -(@sc{rtti}), if the @sc{ansi} committee adopts it into the standard. - -@item -Bring the compiler into closer compliance with the @sc{arm} and the draft -@sc{ansi} standard, and document what points in the @sc{arm} we do not yet comply, -or agree, with. - -@item -Add further support for the @sc{dwarf} debugging format. - -@item -Finish the work to make the compiler compliant with @sc{arm} Section 12.6.2, -initializing base classes in declaration order, rather than in the order -that you specify them in a @var{mem-initializer} list. - -@item -Perform a full coverage analysis on the compiler, and weed out unused -code, for a gain in performance and a reduction in the size of the compiler. - -@item -Further improve the multiple inheritance implementation in the -compiler to make it cleaner and more complete. -@end enumerate - -@noindent -As always, we encourage you to make suggestions and ask questions about -@sc{gnu} C++ as a whole, so we can be sure that the end of this project -will bring a compiler that everyone will find essential for C++ and will -meet the needs of the world's C++ community. - -@include templates.texi - -@include gpcompare.texi - -@contents - -@bye |
