man pages for g++
GNU Tools Last change: 30apr1993
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: preprocessing,
compilation, assembly, and linking. This man page contains
full descriptions for only C++ specific aspects of the com-
piler, 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 genera-
tion, which are common to both gcc and g++. For full infor-
mation 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 corresponding to
each source file.
-Dmacro
Define macro macro with the string `1' as its defini-
tion.
-Dmacro=defn
Define macro macro as defn.
-E Stop after the preprocessing stage; do not run the com-
piler proper. The output is preprocessed source code,
which is sent to the standard output.
-fall-virtual
Treat all possible member functions as virtual, impli-
citly. 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 func-
tions will be made through the internal table of vir-
tual 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++ initial-
izes `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 gen-
erating 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 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++ con-
structors 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 collect2, 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 func-
tion 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 com-
piler 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 func-
tion 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. Oth-
erwise, 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 say-
ing 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 unneces-
sary 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 signature
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 compati-
bility, 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 debug-
ging 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 vari-
ables you declared may not exist at all; flow of con-
trol 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 out-
put. 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++ pro-
grams 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 direc-
tories specific to C++, but do still search the other
standard directories. (This option is used when build-
ing 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 com-
pilers.
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 `-traditional'). If
you need to write header files that work differently
depending on whether `-traditional' is in use, by test-
ing 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 func-
tions must match the type signature of a virtual func-
tion declared in the base class. Use this option to
request warnings when a derived class declares a func-
tion that may be an erroneous attempt to define a vir-
tual 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 debug-
ging 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 per-
mit using the same header file for two purposes: as a defin-
ition 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 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 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; Debugging
with GDB: the GNU Source-Level Debugger, Richard M. Stallman
and Roland H. Pesch; Using as: the GNU Assembler, Dean Els-
ner, Jay Fenlason & friends; gld: the GNU linker, Steve
Chamberlain and Roland Pesch.
BUGS
For instructions on how to report bugs, see the GCC manual.
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 per-
mission notice are preserved on all copies.
Permission is granted to copy and distribute modified ver-
sions of this manual under the conditions for verbatim copy-
ing, provided that the entire resulting derived work is dis-
tributed 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 condi-
tions 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.