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 |
---|