![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to reno.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc / cp|
Return to reno.texi CVS log | Up to [GCC 2.x] / gcc / cp |
1.1 root 1: \input texinfo @c -*- Texinfo -*-
2: @setfilename reno-1.info
3:
4: @ifinfo
5: @format
6: START-INFO-DIR-ENTRY
7: * Reno 1: (reno-1). The GNU C++ Renovation Project, Phase 1.
8: END-INFO-DIR-ENTRY
9: @end format
10: @end ifinfo
11:
12: @ifinfo
13: Copyright @copyright{} 1992, 1993, 1994 Free Software Foundation, Inc.
14:
15: Permission is granted to make and distribute verbatim copies of
16: this manual provided the copyright notice and this permission notice
17: are preserved on all copies.
18:
19: @ignore
20: Permission is granted to process this file through TeX and print the
21: results, provided the printed document carries a copying permission
22: notice identical to this one except for the removal of this paragraph
23: (this paragraph not being relevant to the printed manual).
24:
25: @end ignore
26:
27: Permission is granted to copy and distribute modified versions of this
28: manual under the conditions for verbatim copying, provided also that
29: the entire resulting derived work is distributed under the terms of a
30: permission notice identical to this one.
31:
32: Permission is granted to copy and distribute translations of this manual
33: into another language, under the above conditions for modified versions.
34: @end ifinfo
35:
36: @setchapternewpage odd
37: @settitle GNU C++ Renovation Project
38: @c @smallbook
39:
40: @titlepage
41: @finalout
42: @title GNU C++ Renovation Project
43: @subtitle Phase 1.3
44: @author Brendan Kehoe, Jason Merrill,
45: @author Mike Stump, Michael Tiemann
46: @page
47:
48: Edited March, 1994 by Roland Pesch (@code{pesch@@cygnus.com})
49: @vskip 0pt plus 1filll
50: Copyright @copyright{} 1992, 1993, 1994 Free Software Foundation, Inc.
51:
52: Permission is granted to make and distribute verbatim copies of
53: this manual provided the copyright notice and this permission notice
54: are preserved on all copies.
55:
56: @ignore
57: Permission is granted to process this file through Tex and print the
58: results, provided the printed document carries copying permission
59: notice identical to this one except for the removal of this paragraph
60: (this paragraph not being relevant to the printed manual).
61: @end ignore
62:
63: Permission is granted to copy and distribute modified versions of this
64: manual under the conditions for verbatim copying, provided also that
65: the entire resulting derived work is distributed under the terms of a
66: permission notice identical to this one.
67:
68: Permission is granted to copy and distribute translations of this manual
69: into another language, under the above conditions for modified versions.
70: @end titlepage
71:
72: @ifinfo
73: @node Top
74: @top @sc{gnu} C++ Renovation Project
75:
76: This file describes the goals of the @sc{gnu} C++ Renovation Project,
77: and its accomplishments to date (as of Phase 1.3).
78:
79: It also discusses the remaining divergences from @sc{gnu} C++, and how the
80: name encoding in @sc{gnu} C++ differs from the sample encoding in
81: @cite{The Annotated C++ Reference Manual}.
82: @c This is not a good place to introduce the acronym ARM because it's
83: @c info-only.
84:
85: @menu
86: * Introduction:: What is the GNU C++ Renovation Project?
87: * Changes:: Summary of changes since previous GNU C++ releases.
88: * Plans:: Plans for Reno-2.
89: * Templates:: The template implementation.
90: * ANSI:: GNU C++ conformance to ANSI C++.
91: * Encoding:: Name encoding in GNU C++.
92: @end menu
93:
94: @end ifinfo
95:
96: @node Introduction
97: @chapter Introduction
98:
99: As you may remember, @sc{gnu} C++ was the first native-code C++
100: compiler available under Unix (December 1987). In November 1988, it was
101: judged superior to the AT&T compiler in a Unix World review. In 1990 it
102: won a Sun Observer ``Best-Of'' award. But now, with new requirements
103: coming out of the @sc{ansi} C++ committee and a growing backlog of bugs, it's
104: clear that @sc{gnu} C++ needs an overhaul.
105:
106: The C++ language has been under development since 1982. It has
107: evolved significantly since its original incarnation (C with Classes),
108: addressing many commercial needs and incorporating many lessons
109: learned as more and more people started using ``object-oriented''
110: programming techniques. In 1989, the first X3J16 committee meeting
111: was held in Washington DC; in the interest of users, C++ was going to
112: be standardized.
113:
114: As C++ has become more popular, more demands have been placed on its
115: compilers. Some compilers are up to the demands, others are not.
116: @sc{gnu} C++ was used to prototype several features which have since
117: been incorporated into the standard, most notably exception handling.
118: While @sc{gnu} C++ has been an excellent experimental vehicle, it did
119: not have the resources that AT&T, Borland, or Microsoft have at their
120: disposal.
121:
122: We believe that @sc{gnu} C++ is an important compiler, providing users with
123: many of the features that have made @sc{gnu} C so popular: fast compilation,
124: good error messages, innovative features, and full sources that may be
125: freely redistributed. The purpose of this overhaul, dubbed the @var{@sc{gnu}
126: C++ Renovation Project}, is to take advantage of the functionality that
127: @sc{gnu} C++ offers today, to strengthen its base technology, and put it in a
128: position to remain---as other @sc{gnu} software currently is---the technical
129: leader in the field.
130:
131: This release represents the latest phase of work in strengthening the
132: compiler on a variety of points. It includes many months of
133: work concentrated on fixing many of the more egregious bugs that
134: presented themselves in the compiler recently.
135: @ignore
136: @c FIXME-- update?
137: Nearly 85% of all bugs reported in the period of February to September
138: of 1992 were fixed as part of the work in the first phase.
139: @end ignore
140: In the coming months, we hope to continue expanding and enhancing the
141: quality and dependability of the industry's only freely redistributable
142: C++ compiler.
143:
144: @node Changes
145: @chapter Changes in Behavior in @sc{gnu} C++
146:
147: The @sc{gnu} C++ compiler continues to improve and change. A major goal
148: of our work has been to continue to bring the compiler into compliance
149: with the draft @sc{ansi} C++ standard, and with @cite{The Annotated C++
150: Reference Manual} (the @sc{arm}). This section outlines most of the
151: user-noticeable changes that might be encountered during the normal
152: course of use.
153:
154: @menu
155: * Summary of Phase 1.3::
156: * Major changes::
157: * New features::
158: * Enhancements and bug fixes::
159: * Problems with debugging::
160: @end menu
161:
162: @node Summary of Phase 1.3
163: @section Summary of Changes in Phase 1.3
164:
165: The bulk of this note discusses the cumulative effects of the @sc{gnu} C++
166: Renovation Project to date. The work during its most recent phase (1.3)
167: had these major effects:
168:
169: @itemize @bullet
170: @item The standard compiler driver @code{g++} is now the faster compiled
171: version, rather than a shell script.
172:
173: @item Nested types work much better; notably, nesting is no longer
174: restricted to nine levels.
175:
176: @item Better @sc{arm} conformance on member access control.
177:
178: @item The compiler now always generates default assignment operators
179: (@samp{operator =}), copy constructors (@samp{X::X(X&)}), and default
180: constructors (@samp{X::X()}) whenever they are required.
181:
182: @item The new draft @sc{ansi} standard keyword @code{mutable} is supported.
183:
184: @item @samp{-fansi-overloading} is the default, to comply better with
185: the @sc{arm} (at some cost in compatibility to earlier versions of @sc{gnu} C++).
186:
187: @item More informative error messages.
188:
189: @item System include files are automatically treated as if they were
190: wrapped in @samp{extern "C" @{ @}}.
191:
192: @item The new option @samp{-falt-external-templates} provides alternate
193: template instantiation semantics.
194:
195: @item Operator declarations are now checked more strictly.
196:
197: @item You can now use template type arguments in the template parameter list.
198:
199: @item You can call the destructor for any type.
200:
201: @item The compiler source code is better organized.
202:
203: @item You can specify where to instantiate template definitions explicitly.
204: @end itemize
205:
206: Much of the work in Phase 1.3 went to elimination of known bugs, as well
207: as the major items above.
208:
209: During the span of Phase 1.3, there were also two changes associated
210: with the compiler that, while not specifically part of the C++
211: Renovation project, may be of interest:
212:
213: @itemize @bullet
214: @item @code{gcov}, a code coverage tool for @sc{gnu cc}, is now available
215: from Cygnus Support. (@code{gcov} is free software, but the @sc{fsf} has not
216: yet accepted it.) @xref{Gcov,, @code{gcov}: a Test Coverage Program,
217: gcc.info, Using GNU CC}, for more information (in Cygnus releases of
218: that manual).
219:
220: @item @sc{gnu} C++ now supports @dfn{signatures}, a language extension to
221: provide more flexibility in abstract type definitions. @xref{C++
222: Signatures,, Type Abstraction using Signatures, gcc.info, Using GNU CC}.
223: @end itemize
224:
225: @node Major changes
226: @section Major Changes
227:
228: This release includes four wholesale rewrites of certain areas of
229: compiler functionality:
230:
231: @enumerate 1
232: @item Argument matching. @sc{gnu} C++ is more compliant with the rules
233: described in Chapter 13, ``Overloading'', of the @sc{arm}. This behavior is
234: the default, though you can specify it explicitly with
235: @samp{-fansi-overloading}. For compatibility with earlier releases of
236: @sc{gnu} C++, specify @samp{-fno-ansi-overloading}; this makes the compiler
237: behave as it used to with respect to argument matching and name overloading.
238:
239: @item Default constructors/destructors. Section 12.8 of the @sc{arm}, ``Copying
240: Class Objects'', and Section 12.1, ``Constructors'', state that a
241: compiler must declare such default functions if the user does not
242: specify them. @sc{gnu} C++ now declares, and generates when necessary,
243: the defaults for constructors and destructors you might omit. In
244: particular, assignment operators (@samp{operator =}) behave the same way
245: whether you define them, or whether the compiler generates them by
246: default; taking the address of the default @samp{operator =} is now
247: guaranteed to work. Default copy constructors (@samp{X::X(X&)}) now
248: function correctly, rather than calling the copy assignment operator for
249: the base class. Finally, constructors (@samp{X::X()}), as well as
250: assignment operators and copy constructors, are now available whenever
251: they are required.
252:
253: @c XXX This may be taken out eventually...
254: @item Binary incompatibility. There are no new binary incompatibilities
255: in Phase 1.3, but Phase 1.2 introduced two binary incompatibilities with
256: earlier releases. First, the functionality of @samp{operator
257: new} and @samp{operator delete} changed. Name encoding
258: (``mangling'') of virtual table names changed as well. Libraries
259: built with versions of the compiler earlier than Phase 1.2 must be
260: compiled with the new compiler. (This includes the Cygnus Q2
261: progressive release and the FSF 2.4.5 release.)
262:
263: @item New @code{g++} driver.
264: A new binary @code{g++} compiler driver replaces the shell script.
265: The new driver executes faster.
266: @end enumerate
267:
268: @node New features
269: @section New features
270:
271: @itemize @bullet
272: @item
273: The compiler warns when a class contains only private constructors
274: or destructors, and has no friends. At the request of some of our
275: customers, we have added a new option, @samp{-Wctor-dtor-privacy} (on by
276: default), and its negation, @samp{-Wno-ctor-dtor-privacy}, to control
277: the emission of this warning. If, for example, you are working towards
278: making your code compile warning-free, you can use @w{@samp{-Wall
279: -Wno-ctor-dtor-privacy}} to find the most common warnings.
280:
281: @item
282: There is now a mechanism which controls exactly when templates are
283: expanded, so that you can reduce memory usage and program size and also
284: instantiate them exactly once. You can control this mechanism with the
285: option @samp{-fexternal-templates} and its corresponding negation
286: @samp{-fno-external-templates}. Without this feature, space consumed by
287: template instantiations can grow unacceptably in large-scale projects
288: with many different source files. The default is
289: @samp{-fno-external-templates}.
290:
291: You do not need to use the @samp{-fexternal-templates} option when
292: compiling a file that does not define and instantiate templates used in
293: other files, even if those files @emph{are} compiled with
294: @samp{-fexternal-templates}. The only side effect is an increase in
295: object size for each file that was compiled without
296: @samp{-fexternal-templates}.
297:
298: When your code is compiled with @samp{-fexternal-templates}, all
299: template instantiations are external; this requires that the templates
300: be under the control of @samp{#pragma interface} and @samp{#pragma
301: implementation}. All instantiations that will be needed should be in
302: the implementation file; you can do this with a @code{typedef} that
303: references the instantiation needed. Conversely, when you compile using
304: the option @samp{-fno-external-templates}, all template instantiations are
305: explicitly internal.
306:
307: @samp{-fexternal-templates} also allows you to finally separate class
308: template function definitions from their declarations, thus speeding up
309: compilation times for every file that includes the template declaration.
310: Now you can have tens or even hundreds of lines in template
311: declarations, and thousands or tens of thousands of lines in template
312: definitions, with the definitions only going through the compiler once
313: instead of once for each source file. It is important to note that you
314: must remember to externally instantiate @emph{all} templates that are
315: used from template declarations in interface files. If you forget to do
316: this, unresolved externals will occur.
317:
318: In the example below, the object file generated (@file{example.o}) will
319: contain the global instantiation for @samp{Stack<int>}. If other types
320: of @samp{Stack} are needed, they can be added to @file{example.cc} or
321: placed in a new file, in the same spirit as @file{example.cc}.
322:
323: @code{foo.h}:
324: @smallexample
325: @group
326: #pragma interface "foo.h"
327: template<class T>
328: class Stack @{
329: static int statc;
330: static T statc2;
331: Stack() @{ @}
332: virtual ~Stack() @{ @}
333: int bar();
334: @};
335: @end group
336: @end smallexample
337:
338: @code{example.cc}:
339: @smallexample
340: @group
341: #pragma implementation "foo.h"
342: #include "foo.h"
343:
344: typedef Stack<int> t;
345: int Stack<int>::statc;
346: int Stack<int>::statc2;
347: int Stack<int>::bar() @{ @}
348: @end group
349: @end smallexample
350:
351: Note that using @samp{-fexternal-templates} does not reduce memory usage
352: from completely different instantiations (@samp{Stack<Name>} vs.
353: @samp{Stack<Net_Connection>}), but only collapses different occurrences
354: of @samp{Stack<Name>} so that only one @samp{Stack<Name>} is generated.
355:
356: @samp{-falt-external-templates} selects a slight variation in the
357: semantics described above (incidentally, you need not specify both
358: options; @samp{-falt-external-templates} implies
359: @samp{-fexternal-templates}).
360:
361: With @samp{-fexternal-templates}, the compiler emits a definition in the
362: implementation file that includes the header definition, @emph{even if}
363: instantiation is triggered from a @emph{different} implementation file
364: (e.g. with a template that uses another template).
365:
366: With @samp{-falt-external-templates}, the definition always goes in the
367: implementation file that triggers instantiation.
368:
369: For instance, with these two header files---
370:
371: @example
372: @exdent @file{a.h}:
373: #pragma interface
374: template <class T> class A @{ @dots{} @};
375:
376: @exdent @file{b.h}:
377: #pragma interface
378: class B @{ @dots{} @};
379: void f (A<B>);
380: @end example
381:
382: Under @samp{-fexternal-templates}, the definition of @samp{A<B>} ends up
383: in the implementation file that includes @file{a.h}. Under
384: @samp{-falt-external-templates}, the same definition ends up in the
385: implementation file that includes @file{b.h}.
386:
387: @item
388: You can control explicitly where a template is instantiated, without
389: having to @emph{use} the template to get an instantiation.
390:
391: To instantiate a class template explicitly, write @samp{template
392: class @var{name}<paramvals>}, where @var{paramvals} is a list of values
393: for the template parameters. For example, you might write
394:
395: @example
396: template class A<int>
397: @end example
398:
399: Similarly, to instantiate a function template explicitly, write
400: @samp{template @var{fnsign}} where @var{fnsign} is the particular
401: function signature you need. For example, you might write
402:
403: @example
404: template void foo (int, int)
405: @end example
406:
407: This syntax for explicit template instantiation agrees with recent
408: extensions to the draft @sc{ansi} standard.
409:
410: @item
411: The compiler's actions on @sc{ansi}-related warnings and errors have
412: been further enhanced. The @samp{-pedantic-errors} option produces
413: error messages in a number of new situations: using @code{return} in a
414: non-@code{void} function (one returning a value); declaring a local
415: variable that shadows a parameter (e.g., the function takes an argument
416: @samp{a}, and has a local variable @samp{a}); and use of the @samp{asm}
417: keyword. Finally, the compiler by default now issues a warning when
418: converting from an @code{int} to an enumerated type. This is likely to
419: cause many new warnings in code that hadn't triggered them before. For
420: example, when you compile this code,
421:
422: @smallexample
423: @group
424: enum boolean @{ false, true @};
425: void
426: f ()
427: @{
428: boolean x;
429:
430: x = 1; //@i{assigning an @code{int} to an @code{enum} now triggers a warning}
431: @}
432: @end group
433: @end smallexample
434:
435: @noindent
436: you should see the warning ``@code{anachronistic conversion from integer
437: type to enumeral type `boolean'}''. Instead of assigning the value 1,
438: assign the original enumerated value @samp{true}.
439: @end itemize
440:
441: @node Enhancements and bug fixes
442: @section Enhancements and bug fixes
443:
444: @itemize @bullet
445: @cindex nested types in template parameters
446: @item
447: You can now use nested types in a template parameter list, even if the nested
448: type is defined within the same class that attempts to use the template.
449: For example, given a template @code{list}, the following now works:
450:
451: @smallexample
452: struct glyph @{
453: @dots{}
454: struct stroke @{ @dots{} @};
455: list<stroke> l;
456: @dots{}
457: @}
458: @end smallexample
459:
460: @cindex function pointers vs template parameters
461: @item
462: Function pointers now work in template parameter lists. For
463: example, you might want to instantiate a parameterized @code{list} class
464: in terms of a pointer to a function like this:
465:
466: @smallexample
467: list<int (*)(int, void *)> fnlist;
468: @end smallexample
469:
470: @item
471: @c FIXME! Really no limit? Jason said "deeper than 9" now OK...
472: Nested types are now handled correctly. In particular, there is no
473: longer a limit to how deeply you can nest type definitions.
474:
475: @item
476: @sc{gnu} C++ now conforms to the specifications in Chapter 11 of the
477: @sc{arm}, ``Member Access Control''.
478:
479: @item
480: The @sc{ansi} C++ committee has introduced a new keyword @code{mutable}.
481: @sc{gnu} C++ supports it. Use @code{mutable} to specify that some
482: particular members of a @code{const} class are @emph{not} constant. For
483: example, you can use this to include a cache in a data structure that
484: otherwise represents a read-only database.
485:
486: @item
487: Error messages now explicitly specify the declaration, type, or
488: expression that contains an error.
489:
490: @item
491: To avoid copying and editing all system include files during @sc{gnu}
492: C++ installation, the compiler now automatically recognizes system
493: include files as C language definitions, as if they were wrapped in
494: @samp{extern "C" @{ @dots{} @}}.
495:
496: @item
497: The compiler checks operator declarations more strictly. For example,
498: you may no longer declare an @samp{operator +} with three arguments.
499:
500: @item
501: You can now use template type arguments in the same template
502: parameter list where the type argument is specified (as well as in the
503: template body). For example, you may write
504:
505: @example
506: template <class T, T t> class A @{ @dots{} @};
507: @end example
508:
509: @item
510: Destructors are now available for all types, even built-in ones; for
511: example, you can call @samp{int::~int}. (Destructors for types like
512: @code{int} do not actually do anything, but their existence provides a
513: level of generality that permits smooth template expansion in more
514: cases.)
515:
516: @item
517: Enumerated types declared inside a class are now handled correctly.
518:
519: @item
520: An argument list for a function may not use an initializer list for its default
521: value. For example, @w{@samp{void foo ( T x = @{ 1, 2 @} )}} is not permitted.
522:
523: @item
524: A significant amount of work went into improving the ability of the
525: compiler to act accurately on multiple inheritance and virtual
526: functions. Virtual function dispatch has been enhanced as well.
527:
528: @item
529: The warning concerning a virtual inheritance environment with a
530: non-virtual destructor has been disabled, since it is not clear that
531: such a warning is warranted.
532:
533: @item
534: Until exception handling is fully implemented in the Reno-2 release, use
535: of the identifiers @samp{catch}, @samp{throw}, or @samp{try} results
536: in the warning:
537:
538: @smallexample
539: t.C:1: warning: `catch', `throw', and `try'
540: are all C++ reserved words
541: @end smallexample
542:
543: @item
544: When giving a warning or error concerning initialization of a member in a
545: class, the compiler gives the name of the member if it has one.
546:
547: @item
548: Detecting friendship between classes is more accurately checked.
549:
550: @item
551: The syntaxes of @w{@samp{#pragma implementation "file.h"}} and
552: @samp{#pragma interface} are now more strictly controlled. The compiler
553: notices (and warns) when any text follows @file{file.h} in the
554: implementation pragma, or follows the word @samp{interface}. Any such
555: text is otherwise ignored.
556:
557: @item
558: Trying to declare a template on a variable or type is now considered an
559: error, not an unimplemented feature.
560:
561: @item
562: When an error occurs involving a template, the compiler attempts to
563: tell you at which point of instantiation the error occurred, in
564: addition to noting the line in the template declaration which had the
565: actual error.
566:
567: @item
568: The symbol names for function templates in the resulting assembly file
569: are now encoded according to the arguments, rather than just being
570: emitted as, for example, two definitions of a function @samp{foo}.
571:
572: @item
573: Template member functions that are declared @code{static} no longer
574: receive a @code{this} pointer.
575:
576: @item
577: Case labels are no longer allowed to have commas to make up their
578: expressions.
579:
580: @item
581: Warnings concerning the shift count of a left or right shift now tell
582: you if it was a @samp{left} or @samp{right} shift.
583:
584: @item
585: The compiler now warns when a decimal constant is so large that it
586: becomes @code{unsigned}.
587:
588: @item
589: Union initializers which are raw constructors are now handled properly.
590:
591: @item
592: The compiler no longer gives incorrect errors when initializing a
593: union with an empty initializer list.
594:
595: @item
596: Anonymous unions are now correctly used when nested inside a class.
597:
598: @item
599: Anonymous unions declared as static class members are now handled
600: properly.
601:
602: @item
603: The compiler now notices when a field in a class is declared both as
604: a type and a non-type.
605:
606: @item
607: The compiler now warns when a user-defined function shadows a
608: built-in function, rather than emitting an error.
609:
610: @item
611: A conflict between two function declarations now produces an error
612: regardless of their language context.
613:
614: @item
615: Duplicate definitions of variables with @samp{extern "C"} linkage are no
616: longer considered in error. (Note in C++ linkage---the default---you may
617: not have more than one definition of a variable.)
618:
619: @item
620: Referencing a label that is not defined in any function is now an error.
621:
622: @item
623: The syntax for pointers to methods has been improved; there are still
624: some minor bugs, but a number of cases should now be accepted by the
625: compiler.
626:
627: @item
628: In error messages, arguments are now numbered starting at 1, instead of
629: 0. Therefore, in the function @samp{void foo (int a, int b)}, the
630: argument @samp{a} is argument 1, and @samp{b} is argument 2. There is
631: no longer an argument 0.
632:
633: @item
634: The tag for an enumerator, rather than its value, used as a default
635: argument is now shown in all error messages. For example, @w{@samp{void
636: foo (enum x (= true))}} is shown instead of @w{@samp{void foo (enum x (=
637: 1))}}.
638:
639: @item
640: The @samp{__asm__} keyword is now accepted by the C++ front-end.
641:
642: @item
643: Expressions of the form @samp{foo->~Class()} are now handled properly.
644:
645: @item
646: The compiler now gives better warnings for situations which result in
647: integer overflows (e.g., in storage sizes, enumerators, unary
648: expressions, etc).
649:
650: @item
651: @code{unsigned} bitfields are now promoted to @code{signed int} if the
652: field isn't as wide as an @code{int}.
653:
654: @item
655: Declaration and usage of prefix and postfix @samp{operator ++} and
656: @samp{operator --} are now handled correctly. For example,
657:
658: @smallexample
659: @group
660: class foo
661: @{
662: public:
663: operator ++ ();
664: operator ++ (int);
665: operator -- ();
666: operator -- (int);
667: @};
668:
669: void
670: f (foo *f)
671: @{
672: f++; // @i{call @code{f->operator++(int)}}
673: ++f; // @i{call @code{f->operator++()}}
674: f--; // @i{call @code{f->operator++(int)}}
675: --f; // @i{call @code{f->operator++()}}
676: @}
677: @end group
678: @end smallexample
679:
680: @item
681: In accordance with @sc{arm} section 10.1.1, ambiguities and dominance are now
682: handled properly. The rules described in section 10.1.1 are now fully
683: implemented.
684:
685: @end itemize
686:
687: @node Problems with debugging
688: @section Problems with debugging
689:
690: Two problems remain with regard to debugging:
691:
692: @itemize @bullet
693: @item
694: Debugging of anonymous structures on the IBM RS/6000 host is incorrect.
695:
696: @item
697: Symbol table size is overly large due to redundant symbol information;
698: this can make @code{gdb} coredump under certain circumstances. This
699: problem is not host-specific.
700: @end itemize
701:
702: @node Plans
703: @chapter Plans for Reno-2
704:
705: The overall goal for the second phase of the @sc{gnu} C++ Renovation
706: Project is to bring @sc{gnu} C++ to a new level of reliability, quality,
707: and competitiveness. As particular elements of this strategy, we intend
708: to:
709:
710: @enumerate 0
711: @item
712: Fully implement @sc{ansi} exception handling.
713:
714: @item
715: With the exception handling, add Runtime Type Identification
716: (@sc{rtti}), if the @sc{ansi} committee adopts it into the standard.
717:
718: @item
719: Bring the compiler into closer compliance with the @sc{arm} and the draft
720: @sc{ansi} standard, and document what points in the @sc{arm} we do not yet comply,
721: or agree, with.
722:
723: @item
724: Add further support for the @sc{dwarf} debugging format.
725:
726: @item
727: Finish the work to make the compiler compliant with @sc{arm} Section 12.6.2,
728: initializing base classes in declaration order, rather than in the order
729: that you specify them in a @var{mem-initializer} list.
730:
731: @item
732: Perform a full coverage analysis on the compiler, and weed out unused
733: code, for a gain in performance and a reduction in the size of the compiler.
734:
735: @item
736: Further improve the multiple inheritance implementation in the
737: compiler to make it cleaner and more complete.
738: @end enumerate
739:
740: @noindent
741: As always, we encourage you to make suggestions and ask questions about
742: @sc{gnu} C++ as a whole, so we can be sure that the end of this project
743: will bring a compiler that everyone will find essential for C++ and will
744: meet the needs of the world's C++ community.
745:
746: @include templates.texi
747:
748: @include gpcompare.texi
749:
750: @contents
751:
752: @bye
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.