Computer Science
G++(1) GNU Tools G++(1)
NAME
g++ - GNU project C++ Compiler
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: prepro-
cessing, compilation, assembly, and linking. This man
page contains full descriptions for only C++ specific
aspects of the compiler, though it also contains summaries
of some general-purpose options. For a fuller explanation
of the compiler, see gcc(1).
C++ source files use one of the suffixes `.C', `.cc',
`.cxx', `.cpp', or `.c++'; preprocessed C++ files use the
suffix `.ii'.
OPTIONS
There are many command-line options, including options to
control details of optimization, warnings, and code gener-
ation, which are common 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 compiler output is an object file corre-
sponding to each source file.
-Dmacro
Define macro macro with the string `1' as its defi-
nition.
-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.
-fall-virtual
Treat all possible member functions as virtual,
implicitly. All member functions (except for con-
structor functions and new or delete member opera-
tors) are treated as virtual functions of the class
where they appear.
This does not mean that all calls to these member
functions will be made through the internal table
of virtual functions. Under some circumstances,
the compiler can determine that a call to a given
virtual function can be made directly; in these
cases the calls are direct in any case.
-fdollars-in-identifiers
Permit the use of `$' in identifiers. Traditional
C allowed the character `$' to form part of identi-
fiers; by default, GNU C also allows this. How-
ever, 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 tempo-
rary,
// y is initialized from the tempo-
rary.
Note the difference! With this flag, GNU C++ ini-
tializes `y' directly from the call to foo () with-
out going through a temporary.
-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.
-fexternal-templates
Produce smaller code for template declarations, by
generating only a single copy of each template
function where it is defined. To use this option
successfully, you must also mark all files that use
templates with either `#pragma implementation' (the
definition) or `#pragma interface' (declarations).
When your code is compiled with
`-fexternal-templates', all template instantiations
are external. You must arrange for all necessary
instantiations to appear in the implementation
file; you can do this with a typedef that refer-
ences each instantiation needed. Conversely, when
you compile using the default option
`-fno-external-templates', all template instantia-
tions are explicitly internal.
-fno-gnu-linker
Do not output global initializations (such as C++
constructors and destructors) in the form used by
the GNU linker (on systems where the GNU linker is
the standard method of handling them). Use this
option when you want to use a non-GNU linker, which
also requires using the collect2 program to make
sure the system linker includes constructors and
destructors. (collect2 is included in the GNU CC
distribution.) For systems which must use col-
lect2, the compiler driver gcc is configured to do
this automatically.
-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 com-
pile more slowly (and take more memory).
The first time the compiler must build a call to a
member function (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. Unfortunately, using the cache intro-
duces 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 soft-
ware cache, but when the compiler determines that
the context of the last function compiled would
yield the same access privileges of the next func-
tion to compile, it preserves the cache. This is
most helpful 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
Do not make member functions inline by default
merely because they are defined inside the class
scope. Otherwise, when you specify -O, 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.
-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.
-fhandle-signatures
-fno-handle-signatures
These options control the recognition of the signa-
ture and sigof constructs for specifying abstract
types. By default, these constructs are not recog-
nized.
-fthis-is-variable
The incorporation of user-defined free store man-
agement 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 sys-
tem'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 opti-
mized code may occasionally 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 exe-
cuted 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 opti-
mizer 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 link-
ing.)
-nostdinc
Do not search the standard system directories for
header files. Only the directories you have speci-
fied with -I options (and the current directory, if
appropriate) are searched.
-nostdinc++
Do not search for header files in the standard
directories specific to C++, but do still search
the other standard directories. (This option is
used when building libg++.)
-O Optimize. Optimizing compilation takes somewhat
more time, and a lot more memory for a large func-
tion.
-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.
-traditional
Attempt to support some aspects of traditional C
compilers.
Specifically, for both C and C++ programs:
o In the preprocessor, comments convert to nothing at
all, rather than to a space. This allows tradi-
tional token concatenation.
o In the preprocessor, macro arguments are recognized
within string constants in a macro definition (and
their values are stringified, though without addi-
tional quote marks, when they appear in such a con-
text). The preprocessor always considers a string
constant to end at a newline.
o The preprocessor does not predefine the macro
__STDC__ when you use `-traditional', but still
predefines__GNUC__ (since the GNU extensions indi-
cated by __GNUC__ are not affected by
`-traditional'). If you need to write header files
that work differently 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 com-
pilers, and other old C compilers.
o String ``constants'' are not necessarily constant;
they are stored in writable space, and identical
looking constants are allocated separately.
For C++ programs only (not C), `-traditional' has
one additional effect: assignment to this is per-
mitted. 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 vir-
tual 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 signa-
ture that doesn't match any virtual functions from
the base class.
-Wtemplate-debugging
When using templates in a C++ program, warn if
debugging is not yet fully available.
-w Inhibit all warning messages.
+eN Control how virtual function definitions are used,
in a fashion compatible with cfront 1.x.
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 func-
tions) 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 compilation, this auxiliary information will not
be generated (unless the main input source file
itself uses `#pragma implementation'). 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 gener-
ated (and made globally visible). The included
header file, in turn, should use `#pragma
interface'. Backup copies of inline member func-
tions, debugging information, and the internal
tables used to implement virtual functions are all
generated in implementation files.
If you use `#pragma implementation' with no argu-
ment, 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 sin-
gle 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 ALSO
gcc(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; The C Preprocessor, Richard M. Stallman; Debug-
ging with GDB: the GNU Source-Level Debugger, Richard M.
Stallman and Roland H. Pesch; Using as: the GNU Assembler,
Dean Elsner, Jay Fenlason & friends; gld: the GNU linker,
Steve Chamberlain and Roland Pesch.
BUGS
For instructions on how to report bugs, see the GCC man-
ual.
COPYING
Copyright (c) 1991, 1992, 1993 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 ver-
sions of this manual under the conditions for verbatim
copying, provided that the entire resulting derived work
is distributed under the terms of a permission notice
identical to this one.
Permission is granted to copy and distribute translations
of this manual into another language, under the above con-
ditions for modified versions, except that this permission
notice may be included in translations approved by the
Free Software Foundation instead of in the original
English.
AUTHORS
See the GNU CC Manual for the contributors to GNU CC.
GNU Tools 30apr1993 1
Back to the index
