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