G++(1) GNU Tools G++(1)NAME
g++ - GNU project C++ Compiler (v2 preliminary)
SYNOPSIS
g++ [option | filename ]...
DESCRIPTION
The C and C++ compilers are integrated; g++ is a script to call gcc
with options to recognize C++. gcc processes input files through one
or more of four stages: preprocessing, compilation, assembly, and link‐
ing. This man page contains full descriptions for only C++ specific
aspects of the compiler, though it also contains summaries of some gen‐
eral-purpose options. For a fuller explanation of the compiler, see
gcc(1).
C++ source files use one of the suffixes `.C', `.cc', or `.cxx'; pre‐
processed C++ files use the suffix `.ii'.
OPTIONS
There are many command-line options, including options to control
details of optimization, warnings, and code generation, which are com‐
mon to both gcc and g++. For full information on all options, see
gcc(1).
Options must be separate: `-dr' is quite different from `-d -r '.
Most `-f' and `-W' options have two contrary forms: -fname and
-fno-name (or -Wname and -Wno-name). Only the non-default forms are
shown here.
-c Compile or assemble the source files, but do not link. The com‐
piler output is an object file corresponding to each source
file.
-Dmacro
Define macro macro with the string `1' as its definition.
-Dmacro=defn
Define macro macro as defn.
-E Stop after the preprocessing stage; do not run the compiler
proper. The output is preprocessed source code, which is sent
to the standard output.
+eN control whether virtual function definitions in classes are used
to generate code, or only to define interfaces for their call‐
ers. These options are provided for compatibility with cfront
1.x usage; the recommended GNU C++ usage is to use #pragma
interface and #pragma implementation, instead.
With `+e0', virtual function definitions in classes are declared
extern; the declaration is used only as an interface specifica‐
tion, not to generate code for the virtual functions (in this
compilation).
With `+e1', g++ actually generates the code implementing virtual
functions defined in the code, and makes them publicly visible.
-fall-virtual
When you use the `-fall-virtual', all member functions (except
for constructor functions and new/delete member operators)
declared in the same class with a ``method-call'' operator
method are treated as virtual functions of the given class. In
effect, all of these methods become ``implicitly virtual.''
This does not mean that all calls to these methods will be made
through the internal table of virtual functions. There are some
circumstances under which it is obvious that a call to a given
virtual function can be made directly, and in these cases the
calls still go direct.
The effect of making all methods of a class with a declared
`operator->()()' implicitly virtual using `-fall-virtual'
extends also to all non-constructor methods of any class derived
from such a class.
-fdollars-in-identifiers
Permit the use of `$' in identifiers. Traditional C allowed the
character `$' to form part of identifiers; by default, GNU C
also allows this. However, ANSI C forbids `$' in identifiers,
and GNU C++ also forbids it by default on most platforms (though
on some platforms it's enabled by default for GNU C++ as well).
-felide-constructors
Use this option to instruct the compiler to be smarter about
when it can elide constructors. Without this flag, GNU C++ and
cfront both generate effectively the same code for:
A foo ();
A x (foo ()); // x initialized by `foo ()', no ctor called
A y = foo (); // call to `foo ()' heads to temporary,
// y is initialized from the temporary.
Note the difference! With this flag, GNU C++ initializes `y'
directly from the call to foo () without going through a tempo‐
rary.
-fenum-int-equiv
Normally GNU C++ allows conversion of enum to int, but not the
other way around. Use this option if you want GNU C++ to allow
conversion of int to enum as well.
-fgnu-binutils
-fno-gnu-binutils
`-fgnu-binutils ' (the default for most, but not all, platforms)
makes GNU C++ emit extra information for static initialization
and finalization. This information has to be passed from the
assembler to the GNU linker. Some assemblers won't pass this
information; you must either use GNU as or specify the option
`-fno-gnu-binutils'.
With `-fno-gnu-binutils', you must use the program collect (part
of the GCC distribution) for linking.
-fmemoize-lookups
-fsave-memoized
These flags are used to get the compiler to compile programs
faster using heuristics. They are not on by default since they
are only effective about half the time. The other half of the
time programs compile more slowly (and take more memory).
The first time the compiler must build a call to a member func‐
tion (or reference to a data member), it must (1) determine
whether the class implements member functions of that name; (2)
resolve which member function to call (which involves figuring
out what sorts of type conversions need to be made); and (3)
check the visibility of the member function to the caller. All
of this adds up to slower compilation. Normally, the second
time a call is made to that member function (or reference to
that data member), it must go through the same lengthy process
again. This means that code like this
cout << "This " << p << " has " << n << " legs.\n";
makes six passes through all three steps. By using a software
cache, a ``hit'' significantly reduces this cost. Unfortu‐
nately, using the cache introduces another layer of mechanisms
which must be implemented, and so incurs its own overhead.
`-fmemoize-lookups' enables the software cache.
Because access privileges (visibility) to members and member
functions may differ from one function context to the next, g++
may need to flush the cache. With the `-fmemoize-lookups' flag,
the cache is flushed after every function that is compiled. The
`-fsave-memoized' flag enables the same software cache, but when
the compiler determines that the context of the last function
compiled would yield the same access privileges of the next
function to compile, it preserves the cache. This is most help‐
ful when defining many member functions for the same class: with
the exception of member functions which are friends of other
classes, each member function has exactly the same access privi‐
leges as every other, and the cache need not be flushed.
-fno-default-inline
If `-fdefault-inline' is enabled then member functions defined
inside class scope are compiled inline by default; i.e., you
don't need to add `inline' in front of the member function name.
By popular demand, this option is now the default. To keep GNU
C++ from inlining these member functions, specify
`-fno-default-inline'.
-fno-strict-prototype
Consider the declaration int foo ();. In C++, this means that
the function foo takes no arguments. In ANSI C, this is
declared int foo(void);. With the flag `-fno-strict-prototype',
declaring functions with no arguments is equivalent to declaring
its argument list to be untyped, i.e., int foo (); is equivalent
to saying int foo (...);.
-fnonnull-objects
Normally, GNU C++ makes conservative assumptions about objects
reached through references. For example, the compiler must
check that `a' is not null in code like the following:
obj &a = g ();
a.f (2);
Checking that references of this sort have non-null values
requires extra code, however, and it is unnecessary for many
programs. You can use `-fnonnull-objects' to omit the checks
for null, if your program doesn't require the default checking.
-fthis-is-variable
The incorporation of user-defined free store management into C++
has made assignment to this an anachronism. Therefore, by
default GNU C++ treats the type of this in a member function of
class X to be X *const. In other words, it is illegal to assign
to this within a class member function. However, for backwards
compatibility, you can invoke the old behavior by using
`-fthis-is-variable'.
-g Produce debugging information in the operating system's native
format (for DBX or SDB or DWARF). GDB also can work with this
debugging information. On most systems that use DBX format,
`-g' enables use of extra debugging information that only GDB
can use.
Unlike most other C compilers, GNU CC allows you to use `-g'
with `-O'. The shortcuts taken by optimized code may occasion‐
ally produce surprising results: some variables you declared may
not exist at all; flow of control may briefly move where you did
not expect it; some statements may not be executed because they
compute constant results or their values were already at hand;
some statements may execute in different places because they
were moved out of loops.
Nevertheless it proves possible to debug optimized output. This
makes it reasonable to use the optimizer for programs that might
have bugs.
-Idir Append directory dir to the list of directories searched for
include files.
-Ldir Add directory dir to the list of directories to be searched for
`-l'.
-llibrary
Use the library named library when linking. (C++ programs
often require `-lg++' for successful linking.)
-O Optimize. Optimizing compilation takes somewhat more time, and
a lot more memory for a large function.
Without `-O', the compiler's goal is to reduce the cost of com‐
pilation and to make debugging produce the expected results.
Statements are independent: if you stop the program with a
breakpoint between statements, you can then assign a new value
to any variable or change the program counter to any other
statement in the function and get exactly the results you would
expect from the source code.
Without `-O', only variables declared register are allocated in
registers. The resulting compiled code is a little worse than
produced by PCC without `-O'.
With `-O', the compiler tries to reduce code size and execution
time.
-o file
Place output in file file.
-S Stop after the stage of compilation proper; do not assemble.
The output is an assembler code file for each non-assembler
input file specified.
-static
On systems that support dynamic linking, this prevents linking
with the shared libraries. On other systems, this option has no
effect.
-traditional
Attempt to support some aspects of traditional C compilers.
Specifically, for both C and C++ programs:
· In the preprocessor, comments convert to nothing at all, rather
than to a space. This allows traditional token concatenation.
· In the preprocessor, macro arguments are recognized within
string constants in a macro definition (and their values are
stringified, though without additional quote marks, when they
appear in such a context). The preprocessor always considers a
string constant to end at a newline.
· The preprocessor does not predefine the macro __STDC__ when you
use `-traditional', but still predefines__GNUC__ (since the GNU
extensions indicated by __GNUC__ are not affected by `-tradi‐
tional'). If you need to write header files that work differ‐
ently depending on whether `-traditional' is in use, by testing
both of these predefined macros you can distinguish four situa‐
tions: GNU C, traditional GNU C, other ANSI C compilers, and
other old C compilers.
· In the preprocessor, comments convert to nothing at all, rather
than to a space. This allows traditional token concatenation.
· In the preprocessor, macro arguments are recognized within
string constants in a macro definition (and their values are
stringified, though without additional quote marks, when they
appear in such a context). The preprocessor always considers a
string constant to end at a newline.
· The preprocessor does not predefine the macro __STDC__ when you
use `-traditional', but still predefines__GNUC__ (since the GNU
extensions indicated by __GNUC__ are not affected by `-tradi‐
tional'). If you need to write header files that work differ‐
ently depending on whether `-traditional' is in use, by testing
both of these predefined macros you can distinguish four situa‐
tions: GNU C, traditional GNU C, other ANSI C compilers, and
other old C compilers.
· String ``constants'' are not necessarily constant; they are
stored in writable space, and identical looking constants are
allocated separately. (This is the same as the effect of
`-fwritable-strings'.)
For C++ programs only (not C), `-traditional' has one additional
effect: assignment to this is permitted. This is the same as
the effect of `-fthis-is-variable'.
-Umacro
Undefine macro macro.
-Wall Issue warnings for conditions which pertain to usage that we
recommend avoiding and that we believe is easy to avoid, even in
conjunction with macros.
-Wenum-clash
Warn when converting between different enumeration types.
-Woverloaded-virtual
In a derived class, the definitions of virtual functions must
match the type signature of a virtual function declared in the
base class. Use this option to request warnings when a derived
class declares a function that may be an erroneous attempt to
define a virtual function: that is, warn when a function with
the same name as a virtual function in the base class, but with
a type signature that doesn't match any virtual functions from
the base class.
-w Inhibit all warning messages.
PRAGMAS
Two `#pragma' directives are supported for GNU C++, to permit using the
same header file for two purposes: as a definition of interfaces to a
given object class, and as the full definition of the contents of that
object class.
#pragma interface
Use this directive in header files that define object classes,
to save space in most of the object files that use those
classes. Normally, local copies of certain information (backup
copies of inline member functions, debugging information, and
the internal tables that implement virtual functions) must be
kept in each object file that includes class definitions. You
can use this pragma to avoid such duplication. When a header
file containing `#pragma interface' is included in a compila‐
tion, this auxiliary information will not be generated (unless
the main input source file itself uses `#pragma implementa‐
tion'). Instead, the object files will contain references to be
resolved at link time.
#pragma implementation
#pragma implementation "objects.h"
Use this pragma in a main input file, when you want full output
from included header files to be generated (and made globally
visible). The included header file, in turn, should use
`#pragma interface'. Backup copies of inline member functions,
debugging information, and the internal tables used to implement
virtual functions are all generated in implementation files.
If you use `#pragma implementation' with no argument, it applies
to an include file with the same basename as your source file;
for example, in `allclass.cc', `#pragma implementation' by
itself is equivalent to `#pragma implementation "allclass.h"'.
Use the string argument if you want a single implementation file
to include code from multiple header files.
There is no way to split up the contents of a single header file
into multiple implementation files.
FILES
file.h C header (preprocessor) file
file.i preprocessed C source file
file.C C++ source file
file.cc C++ source file
file.cxx C++ source file
file.s assembly language file
file.o object file
a.out link edited output
TMPDIR/cc∗ temporary files
LIBDIR/cpp preprocessor
LIBDIR/cc1plus compiler
LIBDIR/collect linker front end needed on some machines
LIBDIR/libgcc.a GCC subroutine library
/lib/crt[01n].o start-up routine
LIBDIR/ccrt0 additional start-up routine for C++
/lib/libc.a standard C library, see intro(3)
/usr/include standard directory for #include files
LIBDIR/include standard gcc directory for #include files
LIBDIR/g++-include additional g++ directory for #include
LIBDIR is usually /usr/local/lib/machine/version.
TMPDIR comes from the environment variable TMPDIR (default /usr/tmp if
available, else /tmp).
SEE ALSOgcc(1), cpp(1), as(1), ld(1), gdb(1), adb(1), dbx(1), sdb(1).
`gcc', `cpp', `as',`ld', and `gdb' entries in info.
Using and Porting GNU CC (for version 2.0), Richard M. Stallman, Novem‐
ber 1990; The C Preprocessor, Richard M. Stallman, July 1990; Using
GDB: A Guide to the GNU Source-Level Debugger, Richard M. Stallman and
Roland H. Pesch, December 1991; Using as: the GNU Assembler, Dean
Elsner, Jay Fenlason & friends, March 1991; gld: the GNU linker, Steve
Chamberlain and Roland Pesch, April 1991.
BUGS
Report bugs to bug-g++@prep.ai.mit.edu. Bugs tend actually to be fixed
if they can be isolated, so it is in your interest to report them in
such a way that they can be easily reproduced.
COPYING
Copyright (c) 1991 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a per‐
mission notice identical to this one.
Permission is granted to copy and distribute translations of this man‐
ual into another language, under the above conditions for modified ver‐
sions, except that this permission notice may be included in transla‐
tions approved by the Free Software Foundation instead of in the origi‐
nal English.
AUTHORS
See the GNU CC Manual for the contributors to GNU CC.
GNU Tools 27dec1991 G++(1)