The C and C++ compilers are integrated; g++(1) is a
script to call gcc(1) with options to recognize C++. The
gcc(1) utility processes input files through one or more of
four stages: preprocessing, compilation, assembly, and linking.
This topic 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,
or .cxx; 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(1) and g++(1). 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 corresponding to each source
file.
-Dmacro
Define macro with the string -1 as its
definition.
-Dmacro=defn
Define 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 (although on some platforms, it is
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
Usually, GNU C++ allows conversion of enum to int, but does not
allow conversion from int to enum. Use this option if you want GNU
C++ to allow conversion of int to enum.
-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 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 ensure that the system
linker includes constructors and destructors. (Collect2 is included
in the GNU CC distribution.) For systems that must use Collect2,
the compiler driver gcc(1) is configured to do this
automatically.
-fmemoize-lookups
-fsave-memoized
These flags 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:
determine whether the class implements member functions of that
name;
resolve which member function to call (which involves figuring
out what sorts of type conversions need to be made); and
check the visibility of the member function to the caller.
All of this results in slower compilation. Usually, 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 the following code:
cout << "This " << p << " has " << n << " legs.0;
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 that must be
implemented, and so incurs its own overhead. The
-fmemoize-lookups option enables the software cache.
Because access privileges (visibility) to members and member
functions can differ from one function context to the next,
g++(1) 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 that 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; that is, you need not 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; that is, 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 does not 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
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 can also 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 -g
with -O. The shortcuts taken by optimized code can
occasionally produce surprising results: some variables you
declared might not exist at all; flow of control may briefly move
where you did not expect it; some statements might not be executed
because they compute constant results or their values were already
at hand; and some statements might 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.
-ofile
Place output in 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:
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
supplied as strings, 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
-traditional). If you must write header files that work
differently depending on whether -traditional 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.
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.
-Wall
Issue warnings for conditions which pertain to usage that we
recommend avoiding and which 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 is defined with the
same name as a virtual function in the base class, but with a type
signature that does not 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) 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 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. 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 base name 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.
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 Elsner, Jay Fenlason & friends; gld: the GNU linker
Steve Chamberlain and Roland Pesch.
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.