|
|
1.1 root 1: .\" Copyright (c) 1991, 1992 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 "30apr1993" "GNU Tools" "GNU Tools"
5: .de BP
6: .sp
7: .ti \-.2i
8: \(**
9: ..
10: .SH NAME
11: g++ \- GNU project C++ Compiler (v2.4)
12: .SH SYNOPSIS
13: .RB g++ " [" \c
14: .IR option " | " filename " ].\|.\|.
15: .SH DESCRIPTION
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
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
36: \&\|'; preprocessed C++ files use the suffix `\|\c
37: .B .ii\c
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: .B \-fall\-virtual
94: Treat all possible member functions as virtual, implicitly. All
95: member functions (except for constructor functions and
96: .B new
97: or
98: .B delete
99: member operators) are treated as virtual functions of the class where
100: they appear.
101:
102: This does not mean that all calls to these member functions will be
103: made through the internal table of virtual functions. Under some
104: circumstances, the compiler can determine that a call to a given
105: virtual function can be made directly; in these cases the calls are
106: direct in any case.
107: .TP
108: .B \-fdollars\-in\-identifiers
109: Permit the use of `\|\c
110: .B $\c
111: \&\|' in identifiers.
112: Traditional C allowed the character `\|\c
113: .B $\c
114: \&\|' to form part of identifiers; by default, GNU C also
115: allows this. However, ANSI C forbids `\|\c
116: .B $\c
117: \&\|' in identifiers, and GNU C++ also forbids it by default on most
118: platforms (though on some platforms it's enabled by default for GNU
119: C++ as well).
120: .TP
121: .B \-felide\-constructors
122: Use this option to instruct the compiler to be smarter about when it can
123: elide constructors. Without this flag, GNU C++ and cfront both
124: generate effectively the same code for:
125: .sp
126: .br
127: A\ foo\ ();
128: .br
129: A\ x\ (foo\ ());\ \ \ //\ x\ initialized\ by\ `foo\ ()',\ no\ ctor\ called
130: .br
131: A\ y\ =\ foo\ ();\ \ \ //\ call\ to\ `foo\ ()'\ heads\ to\ temporary,
132: .br
133: \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ //\ y\ is\ initialized\ from\ the\ temporary.
134: .br
135: .sp
136: Note the difference! With this flag, GNU C++ initializes `\|\c
137: .B y\c
138: \&\|' directly
139: from the call to
140: .B foo ()
141: without going through a temporary.
142: .TP
143: .B \-fenum\-int\-equiv
144: Normally GNU C++ allows conversion of
145: .B enum
146: to
147: .B int\c
148: \&, but not the other way around. Use this option if you want GNU C++
149: to allow conversion of
150: .B int
151: to
152: .B enum
153: as well.
154: .TP
155: .B \-fexternal\-templates
156: Produce smaller code for template declarations, by generating only a
157: single copy of each template function where it is defined.
158: To use this option successfully, you must also mark all files that
159: use templates with either `\|\c
160: .B #pragma implementation\c
161: \&\|' (the definition) or
162: `\|\c
163: .B #pragma interface\c
164: \&\|' (declarations).
165:
166: When your code is compiled with `\|\c
167: .B \-fexternal\-templates\c
168: \&\|', all
169: template instantiations are external. You must arrange for all
170: necessary instantiations to appear in the implementation file; you can
171: do this with a \c
172: .B typedef\c
173: \& that references each instantiation needed.
174: Conversely, when you compile using the default option
175: `\|\c
176: .B \-fno\-external\-templates\c
177: \&\|', all template instantiations are
178: explicitly internal.
179: .TP
180: .B \-fno\-gnu\-linker
181: Do not output global initializations (such as C++ constructors and
182: destructors) in the form used by the GNU linker (on systems where the GNU
183: linker is the standard method of handling them). Use this option when
184: you want to use a non-GNU linker, which also requires using the
185: .B collect2
186: program to make sure the system linker includes
187: constructors and destructors. (\c
188: .B collect2
189: is included in the GNU CC distribution.) For systems which
190: .I must
191: use
192: .B collect2\c
193: \&, the compiler driver
194: .B gcc
195: is configured to do this automatically.
196: .TP
197: .B \-fmemoize\-lookups
198: .TP
199: .B \-fsave\-memoized
200: These flags are used to get the compiler to compile programs faster
201: using heuristics. They are not on by default since they are only effective
202: about half the time. The other half of the time programs compile more
203: slowly (and take more memory).
204:
205: The first time the compiler must build a call to a member function (or
206: reference to a data member), it must (1) determine whether the class
207: implements member functions of that name; (2) resolve which member
208: function to call (which involves figuring out what sorts of type
209: conversions need to be made); and (3) check the visibility of the member
210: function to the caller. All of this adds up to slower compilation.
211: Normally, the second time a call is made to that member function (or
212: reference to that data member), it must go through the same lengthy
213: process again. This means that code like this
214: .sp
215: .br
216: \ \ cout\ <<\ "This\ "\ <<\ p\ <<\ "\ has\ "\ <<\ n\ <<\ "\ legs.\en";
217: .br
218: .sp
219: makes six passes through all three steps. By using a software cache,
220: a ``hit'' significantly reduces this cost. Unfortunately, using the
221: cache introduces another layer of mechanisms which must be implemented,
222: and so incurs its own overhead. `\|\c
223: .B \-fmemoize\-lookups\c
224: \&\|' enables
225: the software cache.
226:
227: Because access privileges (visibility) to members and member functions
228: may differ from one function context to the next,
229: .B g++
230: may need to flush the cache. With the `\|\c
231: .B \-fmemoize\-lookups\c
232: \&\|' flag, the cache is flushed after every
233: function that is compiled. The `\|\c
234: \-fsave\-memoized\c
235: \&\|' flag enables the same software cache, but when the compiler
236: determines that the context of the last function compiled would yield
237: the same access privileges of the next function to compile, it
238: preserves the cache.
239: This is most helpful when defining many member functions for the same
240: class: with the exception of member functions which are friends of
241: other classes, each member function has exactly the same access
242: privileges as every other, and the cache need not be flushed.
243: .TP
244: .B \-fno\-default\-inline
245: Do not make member functions inline by default merely because they are
246: defined inside the class scope. Otherwise, when you specify
247: .B \-O\c
248: \&, member functions defined inside class scope are compiled
249: inline by default; i.e., you don't need to add `\|\c
250: .B inline\c
251: \&\|' in front of
252: the member function name.
253: .TP
254: .B \-fno\-strict\-prototype
255: Consider the declaration \c
256: .B int foo ();\c
257: \&. In C++, this means that the
258: function \c
259: .B foo\c
260: \& takes no arguments. In ANSI C, this is declared
261: .B int foo(void);\c
262: \&. With the flag `\|\c
263: .B \-fno\-strict\-prototype\c
264: \&\|',
265: declaring functions with no arguments is equivalent to declaring its
266: argument list to be untyped, i.e., \c
267: .B int foo ();\c
268: \& is equivalent to
269: saying \c
270: .B int foo (...);\c
271: \&.
272: .TP
273: .B \-fnonnull\-objects
274: Normally, GNU C++ makes conservative assumptions about objects reached
275: through references. For example, the compiler must check that `\|\c
276: .B a\c
277: \&\|' is not null in code like the following:
278: .br
279: \ \ \ \ obj\ &a\ =\ g\ ();
280: .br
281: \ \ \ \ a.f\ (2);
282: .br
283: Checking that references of this sort have non-null values requires
284: extra code, however, and it is unnecessary for many programs. You can
285: use `\|\c
286: .B \-fnonnull\-objects\c
287: \&\|' to omit the checks for null, if your program doesn't require the
288: default checking.
289: .TP
290: .B \-fhandle\-signatures
291: .TP
292: .B \-fno\-handle\-signatures
293: These options control the recognition of the \c
294: .B signature\c
295: \& and \c
296: .B sigof\c
297: \& constructs for specifying abstract types. By default, these
298: constructs are not recognized.
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 \-nostdinc
368: Do not search the standard system directories for header files. Only
369: the directories you have specified with
370: .B \-I
371: options (and the current directory, if appropriate) are searched.
372: .TP
373: .B \-nostdinc++
374: Do not search for header files in the standard directories specific to
375: C++, but do still search the other standard directories. (This option
376: is used when building libg++.)
377: .TP
378: .B \-O
379: Optimize. Optimizing compilation takes somewhat more time, and a lot
380: more memory for a large function.
381: .TP
382: .BI "\-o " file\c
383: \&
384: Place output in file \c
385: .I file\c
386: \&.
387: .TP
388: .B \-S
389: Stop after the stage of compilation proper; do not assemble. The output
390: is an assembler code file for each non-assembler input
391: file specified.
392: .TP
393: .B \-traditional
394: Attempt to support some aspects of traditional C compilers.
395:
396: Specifically, for both C and C++ programs:
397: .TP
398: \ \ \ \(bu
399: In the preprocessor, comments convert to nothing at all, rather than
400: to a space. This allows traditional token concatenation.
401: .TP
402: \ \ \ \(bu
403: In the preprocessor, macro arguments are recognized within string
404: constants in a macro definition (and their values are stringified,
405: though without additional quote marks, when they appear in such a
406: context). The preprocessor always considers a string constant to end
407: at a newline.
408: .TP
409: \ \ \ \(bu
410: The preprocessor does not predefine the macro \c
411: .B __STDC__\c
412: \& when you use
413: `\|\c
414: .B \-traditional\c
415: \&\|', but still predefines\c
416: .B __GNUC__\c
417: \& (since the GNU extensions indicated by
418: .B __GNUC__\c
419: \& are not affected by
420: `\|\c
421: .B \-traditional\c
422: \&\|'). If you need to write header files that work
423: differently depending on whether `\|\c
424: .B \-traditional\c
425: \&\|' is in use, by
426: testing both of these predefined macros you can distinguish four
427: situations: GNU C, traditional GNU C, other ANSI C compilers, and
428: other old C compilers.
429: .TP
430: \ \ \ \(bu
431: In the preprocessor, comments convert to nothing at all, rather than
432: to a space. This allows traditional token concatenation.
433: .TP
434: \ \ \ \(bu
435: In the preprocessor, macro arguments are recognized within string
436: constants in a macro definition (and their values are stringified,
437: though without additional quote marks, when they appear in such a
438: context). The preprocessor always considers a string constant to end
439: at a newline.
440: .TP
441: \ \ \ \(bu
442: The preprocessor does not predefine the macro \c
443: .B __STDC__\c
444: \& when you use
445: `\|\c
446: .B \-traditional\c
447: \&\|', but still predefines\c
448: .B __GNUC__\c
449: \& (since the GNU extensions indicated by
450: .B __GNUC__\c
451: \& are not affected by
452: `\|\c
453: .B \-traditional\c
454: \&\|'). If you need to write header files that work
455: differently depending on whether `\|\c
456: .B \-traditional\c
457: \&\|' is in use, by
458: testing both of these predefined macros you can distinguish four
459: situations: GNU C, traditional GNU C, other ANSI C compilers, and
460: other old C compilers.
461: .PP
462: .TP
463: \ \ \ \(bu
464: String ``constants'' are not necessarily constant; they are stored in
465: writable space, and identical looking constants are allocated
466: separately.
467:
468: For C++ programs only (not C), `\|\c
469: .B \-traditional\c
470: \&\|' has one additional effect: assignment to
471: .B this
472: is permitted. This is the same as the effect of `\|\c
473: .B \-fthis\-is\-variable\c
474: \&\|'.
475: .TP
476: .BI \-U macro
477: Undefine macro \c
478: .I macro\c
479: \&.
480: .TP
481: .B \-Wall
482: Issue warnings for conditions which pertain to usage that we recommend
483: avoiding and that we believe is easy to avoid, even in conjunction
484: with macros.
485: .TP
486: .B \-Wenum\-clash
487: Warn when converting between different enumeration types.
488: .TP
489: .B \-Woverloaded\-virtual
490: In a derived class, the definitions of virtual functions must match
491: the type signature of a virtual function declared in the base class.
492: Use this option to request warnings when a derived class declares a
493: function that may be an erroneous attempt to define a virtual
494: function: that is, warn when a function with the same name as a
495: virtual function in the base class, but with a type signature that
496: doesn't match any virtual functions from the base class.
497: .TP
498: .B \-Wtemplate\-debugging
499: When using templates in a C++ program, warn if debugging is not yet
500: fully available.
501: .TP
502: .B \-w
503: Inhibit all warning messages.
504: .TP
505: .BI +e N
506: Control how virtual function definitions are used, in a fashion
507: compatible with
508: .B cfront
509: 1.x.
510: .PP
511:
512: .SH PRAGMAS
513: Two `\|\c
514: .B #pragma\c
515: \&\|' directives are supported for GNU C++, to permit using the same
516: header file for two purposes: as a definition of interfaces to a given
517: object class, and as the full definition of the contents of that object class.
518: .TP
519: .B #pragma interface
520: Use this directive in header files that define object classes, to save
521: space in most of the object files that use those classes. Normally,
522: local copies of certain information (backup copies of inline member
523: functions, debugging information, and the internal tables that
524: implement virtual functions) must be kept in each object file that
525: includes class definitions. You can use this pragma to avoid such
526: duplication. When a header file containing `\|\c
527: .B #pragma interface\c
528: \&\|' is included in a compilation, this auxiliary information
529: will not be generated (unless the main input source file itself uses
530: `\|\c
531: .B #pragma implementation\c
532: \&\|'). Instead, the object files will contain references to be
533: resolved at link time.
534: .tr !"
535: .TP
536: .B #pragma implementation
537: .TP
538: .BI "#pragma implementation !" objects .h!
539: Use this pragma in a main input file, when you want full output from
540: included header files to be generated (and made globally visible).
541: The included header file, in turn, should use `\|\c
542: .B #pragma interface\c
543: \&\|'.
544: Backup copies of inline member functions, debugging information, and
545: the internal tables used to implement virtual functions are all
546: generated in implementation files.
547:
548: If you use `\|\c
549: .B #pragma implementation\c
550: \&\|' with no argument, it applies to an include file with the same
551: basename as your source file; for example, in `\|\c
552: .B allclass.cc\c
553: \&\|', `\|\c
554: .B #pragma implementation\c
555: \&\|' by itself is equivalent to `\|\c
556: .B
557: #pragma implementation "allclass.h"\c
558: \&\|'. Use the string argument if you want a single implementation
559: file to include code from multiple header files.
560:
561: There is no way to split up the contents of a single header file into
562: multiple implementation files.
563: .SH FILES
564: .ta \w'LIBDIR/g++\-include 'u
565: file.h C header (preprocessor) file
566: .br
567: file.i preprocessed C source file
568: .br
569: file.C C++ source file
570: .br
571: file.cc C++ source file
572: .br
573: file.cxx C++ source file
574: .br
575: file.s assembly language file
576: .br
577: file.o object file
578: .br
579: a.out link edited output
580: .br
581: \fITMPDIR\fR/cc\(** temporary files
582: .br
583: \fILIBDIR\fR/cpp preprocessor
584: .br
585: \fILIBDIR\fR/cc1plus compiler
586: .br
587: \fILIBDIR\fR/collect linker front end needed on some machines
588: .br
589: \fILIBDIR\fR/libgcc.a GCC subroutine library
590: .br
591: /lib/crt[01n].o start-up routine
592: .br
593: \fILIBDIR\fR/ccrt0 additional start-up routine for C++
594: .br
595: /lib/libc.a standard C library, see
596: .IR intro (3)
597: .br
598: /usr/include standard directory for
599: .B #include
600: files
601: .br
602: \fILIBDIR\fR/include standard gcc directory for
603: .B #include
604: files
605: .br
606: \fILIBDIR\fR/g++\-include additional g++ directory for
607: .B #include
608: .sp
609: .I LIBDIR
610: is usually
611: .B /usr/local/lib/\c
612: .IR machine / version .
613: .br
614: .I TMPDIR
615: comes from the environment variable
616: .B TMPDIR
617: (default
618: .B /usr/tmp
619: if available, else
620: .B /tmp\c
621: \&).
622: .SH "SEE ALSO"
623: gcc(1), cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1).
624: .br
625: .RB "`\|" gcc "\|', `\|" cpp \|',
626: .RB `\| as \|', `\| ld \|',
627: and
628: .RB `\| gdb \|'
629: entries in
630: .B info\c
631: \&.
632: .br
633: .I
634: Using and Porting GNU CC (for version 2.0)\c
635: , Richard M. Stallman;
636: .I
637: The C Preprocessor\c
638: , Richard M. Stallman;
639: .I
640: Debugging with GDB: the GNU Source-Level Debugger\c
641: , Richard M. Stallman and Roland H. Pesch;
642: .I
643: Using as: the GNU Assembler\c
644: , Dean Elsner, Jay Fenlason & friends;
645: .I
646: gld: the GNU linker\c
647: , Steve Chamberlain and Roland Pesch.
648:
649: .SH BUGS
650: For instructions on how to report bugs, see the GCC manual.
651:
652: .SH COPYING
653: Copyright (c) 1991, 1992, 1993 Free Software Foundation, Inc.
654: .PP
655: Permission is granted to make and distribute verbatim copies of
656: this manual provided the copyright notice and this permission notice
657: are preserved on all copies.
658: .PP
659: Permission is granted to copy and distribute modified versions of this
660: manual under the conditions for verbatim copying, provided that the
661: entire resulting derived work is distributed under the terms of a
662: permission notice identical to this one.
663: .PP
664: Permission is granted to copy and distribute translations of this
665: manual into another language, under the above conditions for modified
666: versions, except that this permission notice may be included in
667: translations approved by the Free Software Foundation instead of in
668: the original English.
669: .SH AUTHORS
670: 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.