g++ - GNU project C++ Compiler
g++ [option | filename ]...
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 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'.
There are many command-line options, including options to
control details of optimization, warnings, and code generation,
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 nondefault
forms are shown here.
-c Compile or assemble the source files, but do not
link. The compiler 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.
-fall-virtual
Treat all possible member functions as virtual,
implicitly. All member functions (except for constructor
functions and new or delete member operators)
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 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 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-tem-
plates', 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 references each instantiation
needed. Conversely, when you compile using
the default option `-fno-external-templates', all
template instantiations 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 compile
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 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 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 privileges
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 `-fnon-
null-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 recognized.
-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-vari-
able'.
-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 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 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.)
-nostdinc
Do not search the standard system directories for
header files. Only the directories you have
specified 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 function.
-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 traditional
token concatenation.
o 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.
o 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 differently depending on whether `-tradi-
tional' is in use, by testing both of these predefined
macros you can distinguish four situations:
GNU C, traditional GNU C, other ANSI C compilers,
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 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.
-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.
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 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 generated
(and made globally visible). The included
header file, in turn, should use `#pragma inter-
face'. 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 `all-
class.cc', `#pragma implementation' by itself is
equivalent to `#pragma implementation "all-
class.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.
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).
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.
For instructions on how to report bugs, see the GCC manual.
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 versions
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 conditions
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.
See the GNU CC Manual for the contributors to GNU CC.
GNU Tools 30apr1993 G++(1)
[ Back ] |
