![[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 [Apple XNU] / GNUtools / cc|
Return to g++.1 CVS log | Up to [Apple XNU] / GNUtools / cc |
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 \-fthis\-is\-variable
291: The incorporation of user-defined free store management into C++ has
292: made assignment to \c
293: .B this\c
294: \& an anachronism. Therefore, by default GNU
295: C++ treats the type of \c
296: .B this\c
297: \& in a member function of \c
298: .B class X\c
299: \&
300: to be \c
301: .B X *const\c
302: \&. In other words, it is illegal to assign to
303: \c
304: .B this\c
305: \& within a class member function. However, for backwards
306: compatibility, you can invoke the old behavior by using
307: \&`\|\c
308: .B \-fthis\-is\-variable\c
309: \&\|'.
310: .TP
311: .B \-g
312: Produce debugging information in the operating system's native format
313: (for DBX or SDB or DWARF). GDB also can work with this debugging
314: information. On most systems that use DBX format, `\|\c
315: .B \-g\c
316: \&\|' enables use
317: of extra debugging information that only GDB can use.
318:
319: Unlike most other C compilers, GNU CC allows you to use `\|\c
320: .B \-g\c
321: \&\|' with
322: `\|\c
323: .B \-O\c
324: \&\|'. The shortcuts taken by optimized code may occasionally
325: produce surprising results: some variables you declared may not exist
326: at all; flow of control may briefly move where you did not expect it;
327: some statements may not be executed because they compute constant
328: results or their values were already at hand; some statements may
329: execute in different places because they were moved out of loops.
330:
331: Nevertheless it proves possible to debug optimized output. This makes
332: it reasonable to use the optimizer for programs that might have bugs.
333: .TP
334: .BI "\-I" "dir"\c
335: \&
336: Append directory \c
337: .I dir\c
338: \& to the list of directories searched for include files.
339: .TP
340: .BI "\-L" "dir"\c
341: \&
342: Add directory \c
343: .I dir\c
344: \& to the list of directories to be searched
345: for `\|\c
346: .B \-l\c
347: \&\|'.
348: .TP
349: .BI \-l library\c
350: \&
351: Use the library named \c
352: .I library\c
353: \& when linking. (C++ programs often require `\|\c
354: \-lg++\c
355: \&\|' for successful linking.)
356: .TP
357: .B \-nostdinc
358: Do not search the standard system directories for header files. Only
359: the directories you have specified with
360: .B \-I
361: options (and the current directory, if appropriate) are searched.
362: .TP
363: .B \-nostdinc++
364: Do not search for header files in the standard directories specific to
365: C++, but do still search the other standard directories. (This option
366: is used when building libg++.)
367: .TP
368: .B \-O
369: Optimize. Optimizing compilation takes somewhat more time, and a lot
370: more memory for a large function.
371: .TP
372: .BI "\-o " file\c
373: \&
374: Place output in file \c
375: .I file\c
376: \&.
377: .TP
378: .B \-S
379: Stop after the stage of compilation proper; do not assemble. The output
380: is an assembler code file for each non-assembler input
381: file specified.
382: .TP
383: .B \-traditional
384: Attempt to support some aspects of traditional C compilers.
385:
386: Specifically, for both C and C++ programs:
387: .TP
388: \ \ \ \(bu
389: In the preprocessor, comments convert to nothing at all, rather than
390: to a space. This allows traditional token concatenation.
391: .TP
392: \ \ \ \(bu
393: In the preprocessor, macro arguments are recognized within string
394: constants in a macro definition (and their values are stringified,
395: though without additional quote marks, when they appear in such a
396: context). The preprocessor always considers a string constant to end
397: at a newline.
398: .TP
399: \ \ \ \(bu
400: The preprocessor does not predefine the macro \c
401: .B __STDC__\c
402: \& when you use
403: `\|\c
404: .B \-traditional\c
405: \&\|', but still predefines\c
406: .B __GNUC__\c
407: \& (since the GNU extensions indicated by
408: .B __GNUC__\c
409: \& are not affected by
410: `\|\c
411: .B \-traditional\c
412: \&\|'). If you need to write header files that work
413: differently depending on whether `\|\c
414: .B \-traditional\c
415: \&\|' is in use, by
416: testing both of these predefined macros you can distinguish four
417: situations: GNU C, traditional GNU C, other ANSI C compilers, and
418: other old C compilers.
419: .TP
420: \ \ \ \(bu
421: In the preprocessor, comments convert to nothing at all, rather than
422: to a space. This allows traditional token concatenation.
423: .TP
424: \ \ \ \(bu
425: In the preprocessor, macro arguments are recognized within string
426: constants in a macro definition (and their values are stringified,
427: though without additional quote marks, when they appear in such a
428: context). The preprocessor always considers a string constant to end
429: at a newline.
430: .TP
431: \ \ \ \(bu
432: The preprocessor does not predefine the macro \c
433: .B __STDC__\c
434: \& when you use
435: `\|\c
436: .B \-traditional\c
437: \&\|', but still predefines\c
438: .B __GNUC__\c
439: \& (since the GNU extensions indicated by
440: .B __GNUC__\c
441: \& are not affected by
442: `\|\c
443: .B \-traditional\c
444: \&\|'). If you need to write header files that work
445: differently depending on whether `\|\c
446: .B \-traditional\c
447: \&\|' is in use, by
448: testing both of these predefined macros you can distinguish four
449: situations: GNU C, traditional GNU C, other ANSI C compilers, and
450: other old C compilers.
451: .PP
452: .TP
453: \ \ \ \(bu
454: String ``constants'' are not necessarily constant; they are stored in
455: writable space, and identical looking constants are allocated
456: separately.
457:
458: For C++ programs only (not C), `\|\c
459: .B \-traditional\c
460: \&\|' has one additional effect: assignment to
461: .B this
462: is permitted. This is the same as the effect of `\|\c
463: .B \-fthis\-is\-variable\c
464: \&\|'.
465: .TP
466: .BI \-U macro
467: Undefine macro \c
468: .I macro\c
469: \&.
470: .TP
471: .B \-Wall
472: Issue warnings for conditions which pertain to usage that we recommend
473: avoiding and that we believe is easy to avoid, even in conjunction
474: with macros.
475: .TP
476: .B \-Wenum\-clash
477: Warn when converting between different enumeration types.
478: .TP
479: .B \-Woverloaded\-virtual
480: In a derived class, the definitions of virtual functions must match
481: the type signature of a virtual function declared in the base class.
482: Use this option to request warnings when a derived class declares a
483: function that may be an erroneous attempt to define a virtual
484: function: that is, warn when a function with the same name as a
485: virtual function in the base class, but with a type signature that
486: doesn't match any virtual functions from the base class.
487: .TP
488: .B \-Wtemplate\-debugging
489: When using templates in a C++ program, warn if debugging is not yet
490: fully available.
491: .TP
492: .B \-w
493: Inhibit all warning messages.
494: .TP
495: .BI +e N
496: Control how virtual function definitions are used, in a fashion
497: compatible with
498: .B cfront
499: 1.x.
500: .PP
501:
502: .SH PRAGMAS
503: Two `\|\c
504: .B #pragma\c
505: \&\|' directives are supported for GNU C++, to permit using the same
506: header file for two purposes: as a definition of interfaces to a given
507: object class, and as the full definition of the contents of that object class.
508: .TP
509: .B #pragma interface
510: Use this directive in header files that define object classes, to save
511: space in most of the object files that use those classes. Normally,
512: local copies of certain information (backup copies of inline member
513: functions, debugging information, and the internal tables that
514: implement virtual functions) must be kept in each object file that
515: includes class definitions. You can use this pragma to avoid such
516: duplication. When a header file containing `\|\c
517: .B #pragma interface\c
518: \&\|' is included in a compilation, this auxiliary information
519: will not be generated (unless the main input source file itself uses
520: `\|\c
521: .B #pragma implementation\c
522: \&\|'). Instead, the object files will contain references to be
523: resolved at link time.
524: .tr !"
525: .TP
526: .B #pragma implementation
527: .TP
528: .BI "#pragma implementation !" objects .h!
529: Use this pragma in a main input file, when you want full output from
530: included header files to be generated (and made globally visible).
531: The included header file, in turn, should use `\|\c
532: .B #pragma interface\c
533: \&\|'.
534: Backup copies of inline member functions, debugging information, and
535: the internal tables used to implement virtual functions are all
536: generated in implementation files.
537:
538: If you use `\|\c
539: .B #pragma implementation\c
540: \&\|' with no argument, it applies to an include file with the same
541: basename as your source file; for example, in `\|\c
542: .B allclass.cc\c
543: \&\|', `\|\c
544: .B #pragma implementation\c
545: \&\|' by itself is equivalent to `\|\c
546: .B
547: #pragma implementation "allclass.h"\c
548: \&\|'. Use the string argument if you want a single implementation
549: file to include code from multiple header files.
550:
551: There is no way to split up the contents of a single header file into
552: multiple implementation files.
553: .SH FILES
554: .ta \w'LIBDIR/g++\-include 'u
555: file.h C header (preprocessor) file
556: .br
557: file.i preprocessed C source file
558: .br
559: file.C C++ source file
560: .br
561: file.cc C++ source file
562: .br
563: file.cxx C++ source file
564: .br
565: file.s assembly language file
566: .br
567: file.o object file
568: .br
569: a.out link edited output
570: .br
571: \fITMPDIR\fR/cc\(** temporary files
572: .br
573: \fILIBDIR\fR/cpp preprocessor
574: .br
575: \fILIBDIR\fR/cc1plus compiler
576: .br
577: \fILIBDIR\fR/collect linker front end needed on some machines
578: .br
579: \fILIBDIR\fR/libgcc.a GCC subroutine library
580: .br
581: /lib/crt[01n].o start-up routine
582: .br
583: \fILIBDIR\fR/ccrt0 additional start-up routine for C++
584: .br
585: /lib/libc.a standard C library, see
586: .IR intro (3)
587: .br
588: /usr/include standard directory for
589: .B #include
590: files
591: .br
592: \fILIBDIR\fR/include standard gcc directory for
593: .B #include
594: files
595: .br
596: \fILIBDIR\fR/g++\-include additional g++ directory for
597: .B #include
598: .sp
599: .I LIBDIR
600: is usually
601: .B /usr/local/lib/\c
602: .IR machine / version .
603: .br
604: .I TMPDIR
605: comes from the environment variable
606: .B TMPDIR
607: (default
608: .B /usr/tmp
609: if available, else
610: .B /tmp\c
611: \&).
612: .SH "SEE ALSO"
613: gcc(1), cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1).
614: .br
615: .RB "`\|" gcc "\|', `\|" cpp \|',
616: .RB `\| as \|', `\| ld \|',
617: and
618: .RB `\| gdb \|'
619: entries in
620: .B info\c
621: \&.
622: .br
623: .I
624: Using and Porting GNU CC (for version 2.0)\c
625: , Richard M. Stallman;
626: .I
627: The C Preprocessor\c
628: , Richard M. Stallman;
629: .I
630: Debugging with GDB: the GNU Source-Level Debugger\c
631: , Richard M. Stallman and Roland H. Pesch;
632: .I
633: Using as: the GNU Assembler\c
634: , Dean Elsner, Jay Fenlason & friends;
635: .I
636: gld: the GNU linker\c
637: , Steve Chamberlain and Roland Pesch.
638:
639: .SH BUGS
640: For instructions on how to report bugs, see the GCC manual.
641:
642: .SH COPYING
643: Copyright (c) 1991, 1992, 1993 Free Software Foundation, Inc.
644: .PP
645: Permission is granted to make and distribute verbatim copies of
646: this manual provided the copyright notice and this permission notice
647: are preserved on all copies.
648: .PP
649: Permission is granted to copy and distribute modified versions of this
650: manual under the conditions for verbatim copying, provided that the
651: entire resulting derived work is distributed under the terms of a
652: permission notice identical to this one.
653: .PP
654: Permission is granted to copy and distribute translations of this
655: manual into another language, under the above conditions for modified
656: versions, except that this permission notice may be included in
657: translations approved by the Free Software Foundation instead of in
658: the original English.
659: .SH AUTHORS
660: 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.