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