![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to g++.1 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to g++.1 CVS log | Up to [GCC 2.x] / gcc |
1.1 root 1: .\" Copyright (c) 1991 Free Software Foundation -*-Text-*-
2: .\" See section COPYING for conditions for redistribution
3: .\" FIXME: no info here on predefines. Should there be? extra for C++...
4: .TH G++ 1 "27dec1991" "GNU Tools" "GNU Tools"
5: .de BP
6: .sp
7: .ti \-.2i
8: \(**
9: ..
10: .SH NAME
11: g++ \- GNU project C++ Compiler (v2 preliminary)
12: .SH SYNOPSIS
13: .RB g++ " [" \c
14: .IR option " | " filename " ].\|.\|.
15: .SH DESCRIPTION
1.1.1.3 ! root 16: The C and C++ compilers are integrated;
! 17: .B g++
! 18: is a script to call
! 19: .B gcc with options to recognize C++.
! 20: .B gcc
! 21: processes input files
1.1 root 22: through one or more of four stages: preprocessing, compilation,
23: assembly, and linking. This man page contains full descriptions for
24: .I only
25: C++ specific aspects of the compiler, though it also contains
26: summaries of some general-purpose options. For a fuller explanation
27: of the compiler, see
28: .BR gcc ( 1 ).
29:
30: C++ source files use one of the suffixes `\|\c
31: .B .C\c
32: \&\|', `\|\c
33: .B .cc\c
34: \&\|', or `\|\c
35: .B .cxx\c
1.1.1.3 ! root 36: \&\|'; preprocessed C++ files use the suffix `\|\c
! 37: .B .ii\c
1.1 root 38: \&\|'.
39: .SH OPTIONS
40: There are many command-line options, including options to control
41: details of optimization, warnings, and code generation, which are
42: common to both
43: .B gcc
44: and
45: .B g++\c
46: \&. For full information on all options, see
47: .BR gcc ( 1 ).
48:
49: Options must be separate: `\|\c
50: .B \-dr\c
51: \&\|' is quite different from `\|\c
52: .B \-d \-r
53: \&\|'.
54:
55: Most `\|\c
56: .B \-f\c
57: \&\|' and `\|\c
58: .B \-W\c
59: \&\|' options have two contrary forms:
60: .BI \-f name
61: and
62: .BI \-fno\- name\c
63: \& (or
64: .BI \-W name
65: and
66: .BI \-Wno\- name\c
67: \&). Only the non-default forms are shown here.
68:
69: .TP
70: .B \-c
71: Compile or assemble the source files, but do not link. The compiler
72: output is an object file corresponding to each source file.
73: .TP
74: .BI \-D macro
75: Define macro \c
76: .I macro\c
77: \& with the string `\|\c
78: .B 1\c
79: \&\|' as its definition.
80: .TP
81: .BI \-D macro = defn
82: Define macro \c
83: .I macro\c
84: \& as \c
85: .I defn\c
86: \&.
87: .TP
88: .B \-E
89: Stop after the preprocessing stage; do not run the compiler proper. The
90: output is preprocessed source code, which is sent to the
91: standard output.
92: .TP
93: .BI +e N
94: control whether virtual function definitions in classes
95: are used to generate code, or only to define interfaces for their
96: callers. These options are provided for compatibility with cfront
97: 1.x usage; the recommended GNU C++ usage is to use
98: .B #pragma interface
99: and
100: .B
101: #pragma implementation\c
102: \&, instead.
103:
104: With `\|\c
105: .B +e0\c
106: \&\|', virtual function definitions in classes are declared extern;
107: the declaration is used only as an interface specification, not to
108: generate code for the virtual functions (in this compilation).
109:
110: With `\|\c
111: .B +e1\c
112: \&\|',
113: .B g++
114: actually generates the code implementing virtual functions
115: defined in the code, and makes them publicly visible.
116: .TP
117: .B \-fall\-virtual
118: When you use the `\|\c
119: .B \-fall\-virtual\c
120: \&\|', all member functions
121: (except for constructor functions and new/delete member operators)
122: declared in the same class with a ``method-call'' operator method are
123: treated as virtual functions of the given class. In effect, all
124: of these methods become ``implicitly virtual.''
125:
126: This does \c
127: .I not\c
128: \& mean that all calls to these methods will be made through the
129: internal table of virtual functions. There are some circumstances
130: under which it is obvious that a call to a given virtual function can
131: be made directly, and in these cases the calls still go direct.
132:
133: The effect of making all methods of a class with a declared
134: \&`\|\c
135: .B
136: operator->()()\c
137: \&\|' implicitly virtual using `\|\c
138: .B \-fall\-virtual\c
139: \&\|' extends
140: also to all non-constructor methods of any class derived from such a
141: class.
142: .TP
143: .B \-fdollars\-in\-identifiers
144: Permit the use of `\|\c
145: .B $\c
146: \&\|' in identifiers.
147: Traditional C allowed the character `\|\c
148: .B $\c
149: \&\|' to form part of identifiers; by default, GNU C also
150: allows this. However, ANSI C forbids `\|\c
151: .B $\c
152: \&\|' in identifiers, and GNU C++ also forbids it by default on most
153: platforms (though on some platforms it's enabled by default for GNU
154: C++ as well).
155: .TP
156: .B \-felide\-constructors
157: Use this option to instruct the compiler to be smarter about when it can
158: elide constructors. Without this flag, GNU C++ and cfront both
159: generate effectively the same code for:
160: .sp
161: .br
162: A\ foo\ ();
163: .br
164: A\ x\ (foo\ ());\ \ \ //\ x\ initialized\ by\ `foo\ ()',\ no\ ctor\ called
165: .br
166: A\ y\ =\ foo\ ();\ \ \ //\ call\ to\ `foo\ ()'\ heads\ to\ temporary,
167: .br
168: \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ //\ y\ is\ initialized\ from\ the\ temporary.
169: .br
170: .sp
171: Note the difference! With this flag, GNU C++ initializes `\|\c
172: .B y\c
173: \&\|' directly
174: from the call to
175: .B foo ()
176: without going through a temporary.
177: .TP
178: .B \-fenum\-int\-equiv
179: Normally GNU C++ allows conversion of
180: .B enum
181: to
182: .B int\c
183: \&, but not the other way around. Use this option if you want GNU C++
184: to allow conversion of
185: .B int
186: to
187: .B enum
188: as well.
189: .TP
190: .B \-fgnu\-binutils
191: .TP
192: .B \-fno\-gnu\-binutils
193: `\|\c
194: .B \-fgnu\-binutils
195: \&\|' (the default for most, but not all, platforms) makes GNU C++
196: emit extra information for static initialization and finalization.
197: This information has to be passed from the assembler to the GNU
198: linker. Some assemblers won't pass this information; you must either
199: use GNU
200: .B as
201: or specify the option `\|\c
202: .B \-fno\-gnu\-binutils\c
203: \&\|'.
204:
205: With `\|\c
206: .B \-fno\-gnu\-binutils\c
207: \&\|', you must use the program
208: .B collect
209: (part of the GCC distribution) for linking.
210: .TP
211: .B \-fmemoize\-lookups
212: .TP
213: .B \-fsave\-memoized
214: These flags are used to get the compiler to compile programs faster
215: using heuristics. They are not on by default since they are only effective
216: about half the time. The other half of the time programs compile more
217: slowly (and take more memory).
218:
219: The first time the compiler must build a call to a member function (or
220: reference to a data member), it must (1) determine whether the class
221: implements member functions of that name; (2) resolve which member
222: function to call (which involves figuring out what sorts of type
223: conversions need to be made); and (3) check the visibility of the member
224: function to the caller. All of this adds up to slower compilation.
225: Normally, the second time a call is made to that member function (or
226: reference to that data member), it must go through the same lengthy
227: process again. This means that code like this
228: .sp
229: .br
230: \ \ cout\ <<\ "This\ "\ <<\ p\ <<\ "\ has\ "\ <<\ n\ <<\ "\ legs.\en";
231: .br
232: .sp
233: makes six passes through all three steps. By using a software cache,
234: a ``hit'' significantly reduces this cost. Unfortunately, using the
235: cache introduces another layer of mechanisms which must be implemented,
236: and so incurs its own overhead. `\|\c
237: .B \-fmemoize\-lookups\c
238: \&\|' enables
239: the software cache.
240:
241: Because access privileges (visibility) to members and member functions
242: may differ from one function context to the next,
243: .B g++
244: may need to flush the cache. With the `\|\c
245: .B \-fmemoize\-lookups\c
246: \&\|' flag, the cache is flushed after every
247: function that is compiled. The `\|\c
248: \-fsave\-memoized\c
249: \&\|' flag enables the same software cache, but when the compiler
250: determines that the context of the last function compiled would yield
251: the same access privileges of the next function to compile, it
252: preserves the cache.
253: This is most helpful when defining many member functions for the same
254: class: with the exception of member functions which are friends of
255: other classes, each member function has exactly the same access
256: privileges as every other, and the cache need not be flushed.
257: .TP
258: .B \-fno\-default\-inline
259: If `\|\c
260: .B \-fdefault\-inline\c
261: \&\|' is enabled then member functions defined inside class
262: scope are compiled inline by default; i.e., you don't need to
263: add `\|\c
264: .B inline\c
265: \&\|' in front of the member function name. By popular
266: demand, this option is now the default. To keep GNU C++ from inlining
267: these member functions, specify `\|\c
268: .B \-fno\-default\-inline\c
269: \&\|'.
270: .TP
271: .B \-fno\-strict\-prototype
272: Consider the declaration \c
273: .B int foo ();\c
274: \&. In C++, this means that the
275: function \c
276: .B foo\c
277: \& takes no arguments. In ANSI C, this is declared
278: .B int foo(void);\c
279: \&. With the flag `\|\c
280: .B \-fno\-strict\-prototype\c
281: \&\|',
282: declaring functions with no arguments is equivalent to declaring its
283: argument list to be untyped, i.e., \c
284: .B int foo ();\c
285: \& is equivalent to
286: saying \c
287: .B int foo (...);\c
288: \&.
289: .TP
290: .B \-fnonnull\-objects
291: Normally, GNU C++ makes conservative assumptions about objects reached
292: through references. For example, the compiler must check that `\|\c
293: .B a\c
294: \&\|' is not null in code like the following:
295: .br
296: \ \ \ \ obj\ &a\ =\ g\ ();
297: .br
298: \ \ \ \ a.f\ (2);
299: .br
300: Checking that references of this sort have non-null values requires
301: extra code, however, and it is unnecessary for many programs. You can
302: use `\|\c
303: .B \-fnonnull\-objects\c
304: \&\|' to omit the checks for null, if your program doesn't require the
305: default checking.
306: .TP
307: .B \-fthis\-is\-variable
308: The incorporation of user-defined free store management into C++ has
309: made assignment to \c
310: .B this\c
311: \& an anachronism. Therefore, by default GNU
312: C++ treats the type of \c
313: .B this\c
314: \& in a member function of \c
315: .B class X\c
316: \&
317: to be \c
318: .B X *const\c
319: \&. In other words, it is illegal to assign to
320: \c
321: .B this\c
322: \& within a class member function. However, for backwards
323: compatibility, you can invoke the old behavior by using
324: \&`\|\c
325: .B \-fthis\-is\-variable\c
326: \&\|'.
327: .TP
328: .B \-g
329: Produce debugging information in the operating system's native format
330: (for DBX or SDB or DWARF). GDB also can work with this debugging
331: information. On most systems that use DBX format, `\|\c
332: .B \-g\c
333: \&\|' enables use
334: of extra debugging information that only GDB can use.
335:
336: Unlike most other C compilers, GNU CC allows you to use `\|\c
337: .B \-g\c
338: \&\|' with
339: `\|\c
340: .B \-O\c
341: \&\|'. The shortcuts taken by optimized code may occasionally
342: produce surprising results: some variables you declared may not exist
343: at all; flow of control may briefly move where you did not expect it;
344: some statements may not be executed because they compute constant
345: results or their values were already at hand; some statements may
346: execute in different places because they were moved out of loops.
347:
348: Nevertheless it proves possible to debug optimized output. This makes
349: it reasonable to use the optimizer for programs that might have bugs.
350: .TP
351: .BI "\-I" "dir"\c
352: \&
353: Append directory \c
354: .I dir\c
355: \& to the list of directories searched for include files.
356: .TP
357: .BI "\-L" "dir"\c
358: \&
359: Add directory \c
360: .I dir\c
361: \& to the list of directories to be searched
362: for `\|\c
363: .B \-l\c
364: \&\|'.
365: .TP
366: .BI \-l library\c
367: \&
368: Use the library named \c
369: .I library\c
370: \& when linking. (C++ programs often require `\|\c
371: \-lg++\c
372: \&\|' for successful linking.)
373: .TP
374: .B \-O
375: Optimize. Optimizing compilation takes somewhat more time, and a lot
376: more memory for a large function.
377:
378: Without `\|\c
379: .B \-O\c
380: \&\|', the compiler's goal is to reduce the cost of
381: compilation and to make debugging produce the expected results.
382: Statements are independent: if you stop the program with a breakpoint
383: between statements, you can then assign a new value to any variable or
384: change the program counter to any other statement in the function and
385: get exactly the results you would expect from the source code.
386:
387: Without `\|\c
388: .B \-O\c
389: \&\|', only variables declared \c
390: .B register\c
391: \& are
392: allocated in registers. The resulting compiled code is a little worse
393: than produced by PCC without `\|\c
394: .B \-O\c
395: \&\|'.
396:
397: With `\|\c
398: .B \-O\c
399: \&\|', the compiler tries to reduce code size and execution
400: time.
401: .TP
402: .BI "\-o " file\c
403: \&
404: Place output in file \c
405: .I file\c
406: \&.
407: .TP
408: .B \-S
409: Stop after the stage of compilation proper; do not assemble. The output
410: is an assembler code file for each non-assembler input
411: file specified.
412: .TP
413: .B \-static
414: On systems that support dynamic linking, this prevents linking with the shared
1.1.1.3 ! root 415: libraries. On other systems, this option has no effect.
1.1 root 416: .TP
417: .B \-traditional
418: Attempt to support some aspects of traditional C compilers.
419:
420: Specifically, for both C and C++ programs:
421: .TP
422: \ \ \ \(bu
423: In the preprocessor, comments convert to nothing at all, rather than
424: to a space. This allows traditional token concatenation.
425: .TP
426: \ \ \ \(bu
427: In the preprocessor, macro arguments are recognized within string
428: constants in a macro definition (and their values are stringified,
429: though without additional quote marks, when they appear in such a
430: context). The preprocessor always considers a string constant to end
431: at a newline.
432: .TP
433: \ \ \ \(bu
434: The preprocessor does not predefine the macro \c
435: .B __STDC__\c
436: \& when you use
437: `\|\c
438: .B \-traditional\c
439: \&\|', but still predefines\c
440: .B __GNUC__\c
441: \& (since the GNU extensions indicated by
442: .B __GNUC__\c
443: \& are not affected by
444: `\|\c
445: .B \-traditional\c
446: \&\|'). If you need to write header files that work
447: differently depending on whether `\|\c
448: .B \-traditional\c
449: \&\|' is in use, by
450: testing both of these predefined macros you can distinguish four
451: situations: GNU C, traditional GNU C, other ANSI C compilers, and
452: other old C compilers.
453: .TP
454: \ \ \ \(bu
455: In the preprocessor, comments convert to nothing at all, rather than
456: to a space. This allows traditional token concatenation.
457: .TP
458: \ \ \ \(bu
459: In the preprocessor, macro arguments are recognized within string
460: constants in a macro definition (and their values are stringified,
461: though without additional quote marks, when they appear in such a
462: context). The preprocessor always considers a string constant to end
463: at a newline.
464: .TP
465: \ \ \ \(bu
466: The preprocessor does not predefine the macro \c
467: .B __STDC__\c
468: \& when you use
469: `\|\c
470: .B \-traditional\c
471: \&\|', but still predefines\c
472: .B __GNUC__\c
473: \& (since the GNU extensions indicated by
474: .B __GNUC__\c
475: \& are not affected by
476: `\|\c
477: .B \-traditional\c
478: \&\|'). If you need to write header files that work
479: differently depending on whether `\|\c
480: .B \-traditional\c
481: \&\|' is in use, by
482: testing both of these predefined macros you can distinguish four
483: situations: GNU C, traditional GNU C, other ANSI C compilers, and
484: other old C compilers.
485: .PP
486: .TP
487: \ \ \ \(bu
488: String ``constants'' are not necessarily constant; they are stored in
489: writable space, and identical looking constants are allocated
490: separately. (This is the same as the effect of
491: `\|\c
492: .B \-fwritable\-strings\c
493: \&\|'.)
494:
495: For C++ programs only (not C), `\|\c
496: .B \-traditional\c
497: \&\|' has one additional effect: assignment to
498: .B this
499: is permitted. This is the same as the effect of `\|\c
500: .B \-fthis\-is\-variable\c
501: \&\|'.
502: .TP
503: .BI \-U macro
504: Undefine macro \c
505: .I macro\c
506: \&.
507: .TP
508: .B \-Wall
509: Issue warnings for conditions which pertain to usage that we recommend
510: avoiding and that we believe is easy to avoid, even in conjunction
511: with macros.
512: .TP
513: .B \-Wenum\-clash
514: Warn when converting between different enumeration types.
515: .TP
516: .B \-Woverloaded\-virtual
517: In a derived class, the definitions of virtual functions must match
518: the type signature of a virtual function declared in the base class.
519: Use this option to request warnings when a derived class declares a
520: function that may be an erroneous attempt to define a virtual
521: function: that is, warn when a function with the same name as a
522: virtual function in the base class, but with a type signature that
523: doesn't match any virtual functions from the base class.
524: .TP
525: .B \-w
526: Inhibit all warning messages.
527: .PP
528:
529: .SH PRAGMAS
530: Two `\|\c
531: .B #pragma\c
532: \&\|' directives are supported for GNU C++, to permit using the same
533: header file for two purposes: as a definition of interfaces to a given
534: object class, and as the full definition of the contents of that object class.
535: .TP
536: .B #pragma interface
537: Use this directive in header files that define object classes, to save
538: space in most of the object files that use those classes. Normally,
539: local copies of certain information (backup copies of inline member
540: functions, debugging information, and the internal tables that
541: implement virtual functions) must be kept in each object file that
542: includes class definitions. You can use this pragma to avoid such
543: duplication. When a header file containing `\|\c
544: .B #pragma interface\c
545: \&\|' is included in a compilation, this auxiliary information
546: will not be generated (unless the main input source file itself uses
547: `\|\c
548: .B #pragma implementation\c
549: \&\|'). Instead, the object files will contain references to be
550: resolved at link time.
551: .tr !"
552: .TP
553: .B #pragma implementation
554: .TP
555: .BI "#pragma implementation !" objects .h!
556: Use this pragma in a main input file, when you want full output from
557: included header files to be generated (and made globally visible).
558: The included header file, in turn, should use `\|\c
559: .B #pragma interface\c
560: \&\|'.
561: Backup copies of inline member functions, debugging information, and
562: the internal tables used to implement virtual functions are all
563: generated in implementation files.
564:
565: If you use `\|\c
566: .B #pragma implementation\c
567: \&\|' with no argument, it applies to an include file with the same
568: basename as your source file; for example, in `\|\c
569: .B allclass.cc\c
570: \&\|', `\|\c
571: .B #pragma implementation\c
572: \&\|' by itself is equivalent to `\|\c
573: .B
574: #pragma implementation "allclass.h"\c
575: \&\|'. Use the string argument if you want a single implementation
576: file to include code from multiple header files.
577:
578: There is no way to split up the contents of a single header file into
579: multiple implementation files.
580: .SH FILES
581: .ta \w'LIBDIR/g++\-include 'u
582: file.h C header (preprocessor) file
583: .br
584: file.i preprocessed C source file
585: .br
586: file.C C++ source file
587: .br
588: file.cc C++ source file
589: .br
590: file.cxx C++ source file
591: .br
592: file.s assembly language file
593: .br
594: file.o object file
595: .br
596: a.out link edited output
597: .br
598: \fITMPDIR\fR/cc\(** temporary files
599: .br
600: \fILIBDIR\fR/cpp preprocessor
601: .br
602: \fILIBDIR\fR/cc1plus compiler
603: .br
604: \fILIBDIR\fR/collect linker front end needed on some machines
605: .br
606: \fILIBDIR\fR/libgcc.a GCC subroutine library
607: .br
608: /lib/crt[01n].o start-up routine
609: .br
610: \fILIBDIR\fR/ccrt0 additional start-up routine for C++
611: .br
612: /lib/libc.a standard C library, see
613: .IR intro (3)
614: .br
615: /usr/include standard directory for
616: .B #include
617: files
618: .br
619: \fILIBDIR\fR/include standard gcc directory for
620: .B #include
621: files
622: .br
623: \fILIBDIR\fR/g++\-include additional g++ directory for
624: .B #include
625: .sp
626: .I LIBDIR
627: is usually
628: .B /usr/local/lib/\c
629: .IR machine / version .
630: .br
631: .I TMPDIR
632: comes from the environment variable
633: .B TMPDIR
634: (default
635: .B /usr/tmp
636: if available, else
637: .B /tmp\c
638: \&).
639: .SH "SEE ALSO"
640: gcc(1), cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1).
641: .br
642: .RB "`\|" gcc "\|', `\|" cpp \|',
643: .RB `\| as \|', `\| ld \|',
644: and
645: .RB `\| gdb \|'
646: entries in
647: .B info\c
648: \&.
649: .br
650: .I
651: Using and Porting GNU CC (for version 2.0)\c
652: , Richard M. Stallman, November 1990;
653: .I
654: The C Preprocessor\c
655: , Richard M. Stallman, July 1990;
656: .I
657: Using GDB: A Guide to the GNU Source-Level Debugger\c
658: , Richard M. Stallman and Roland H. Pesch, December 1991;
659: .I
660: Using as: the GNU Assembler\c
661: , Dean Elsner, Jay Fenlason & friends, March 1991;
662: .I
663: gld: the GNU linker\c
664: , Steve Chamberlain and Roland Pesch, April 1991.
665:
666: .SH BUGS
667: Report bugs to
1.1.1.3 ! root 668: .BR bug\[email protected] .
1.1 root 669: Bugs tend actually to be fixed if they can be isolated, so it is in your
670: interest to report them in such a way that they can be easily reproduced.
671: .SH COPYING
672: Copyright (c) 1991 Free Software Foundation, Inc.
673: .PP
674: Permission is granted to make and distribute verbatim copies of
675: this manual provided the copyright notice and this permission notice
676: are preserved on all copies.
677: .PP
678: Permission is granted to copy and distribute modified versions of this
679: manual under the conditions for verbatim copying, provided that the
680: entire resulting derived work is distributed under the terms of a
681: permission notice identical to this one.
682: .PP
683: Permission is granted to copy and distribute translations of this
684: manual into another language, under the above conditions for modified
685: versions, except that this permission notice may be included in
686: translations approved by the Free Software Foundation instead of in
687: the original English.
688: .SH AUTHORS
689: See the GNU CC Manual for the contributors to GNU CC.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.