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