This section describes the command-line options that are only meaningful for C++ programs; but you can also use most of the compiler options regardless of what language your program is in. For example, you might compile a file firstClass.C like this:
g++ -g -felide-constructors -O -c firstClass.C
In this example, only “-felide-constructors” is an option meant only for C++ programs; you can use the other options with any language supported by the compiler.
Here is a list of options that are only for compiling C++ programs:
Turn off all access checking. This switch is mainly useful for working around bugs in the access control code.
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. In 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.
Check that the pointer returned by operator new is non-null before attempting to modify the storage allocated. The current Working Paper requires that operator new never return a null pointer, so this check is normally unnecessary.
Put uninitialized or runtime-initialized global variables into the common segment, as C does. This saves space in the executable at the cost of not diagnosing duplicate definitions. If you compile with this flag and your program mysteriously crashes after main() has completed, you may have an object that is being destroyed twice because two definitions were merged.
Accept “$” in identifiers. You can also explicitly prohibit use of “$” with the option “-fno-dollars-in-identifiers”. (GNU C allows “$” by default on most target systems, but there are a few exceptions.) Traditional C allowed the character “$” to form part of identifiers. However, ANSI C and C++ forbid “$” in identifiers.
Anachronistically permit implicit conversion of int to enumeration types. Current C++ allows conversion of enum to int, but not the other way around.
Cause template instantiations to obey “#pragma interface” and “implementation”; template instances are emitted or not according to the location of the template definition. See Section 3.5, for more information.
This option is deprecated.
Similar to -fexternal-templates, but template instances are emitted or not according to the place where they are first instantiated. See Section 3.5, for more information.
This option is deprecated.
If -ffor-scope is specified, the scope of variables declared in a for-init-statement is limited to the “for” loop itself, as specified by the draft C++ standard. If -fno-for-scope is specified, the scope of variables declared in a for-init-statement extends to the end of the enclosing scope, as was the case in old versions of gcc, and other (traditional) implementations of C++.
The default if neither flag is given to follow the standard, but to allow and give a warning for old-style code that would otherwise be invalid, or have different behavior.
Do not recognize classof, headof, signature, sigof or typeof as a keyword, so that code can use these words as identifiers. You can use the keywords __classof__, __headof__, __signature__, __sigof__, and __typeof__ instead. “-ansi” implies “-fno-gnu-keywords”.
Treat a function declaration with the same type as a potential function template instantiation as though it declares that instantiation, not a normal function. If a definition is given for the function later in the translation unit (or another translation unit if the target supports weak symbols), that definition will be used; otherwise the template will be instantiated. This behavior reflects the C++ language prior to September 1996, when guiding declarations were removed.
This option implies “-fname-mangling-version-0”, and will not work with other name mangling versions.
Never emit code for templates that are instantiated implicitly (i.e. by use); only emit code for explicit instantiations. See Section 3.5, for more information.
Recognize the signature and sigof keywords for specifying abstract types. The default (“-fno-handle-signatures”) is not to recognize them. See Section 3.6.
Support virtual function calls for objects that exceed the size representable by a “short int”. Users should not use this flag by default; if you need to use it, the compiler will tell you so. If you compile any of your code with this flag, you must compile all of your code with this flag (including the C++ library, if you use it).
This flag is not useful when compiling with -fvtable-thunks.
To save space, do not emit out-of-line copies of inline functions controlled by “#pragma implementation”. This will cause linker errors if these functions are not inlined everywhere they are called.
Use heuristics to compile faster. These heuristics are not enabled by default, since they are only effective for certain input files. Other input files compile more slowly.
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 that 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 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.
The code that implements these flags has rotted; you should probably avoid using them.
Within an “extern "C"” linkage specification, treat a function declaration with no arguments, such as “int foo ();”, as declaring the function to take no arguments. Normally, such a declaration means that the function foo can take any combination of arguments, as in C. “-pedantic” implies “-fstrict-prototype” unless overridden with “-fno-strict-prototype”.
This flag no longer affects declarations with C++ linkage.
Control the way in which names are mangled. Version 0 is compatible with versions of g++ before 2.8. Version 1 is the default. Version 1 will allow correct mangling of function templates. For example, version 0 mangling does not mangle foo<int, double> and foo<int, char> given this declaration:
template <class T, class U> void foo(T t);
Don't assume that a reference is initialized to refer to a valid object. Although the current C++ Working Paper prohibits null references, some old code may rely on them, and you can use “-fno-nonnull-objects” to turn on checking.
At the moment, the compiler only does this checking for conversions to virtual base classes.
Recognize the operator name keywords and, bitand, bitor, compl, not, or and xor as synonyms for the symbols they refer to. “-ansi” implies “-foperator-names”.
Permit assignment to this. The incorporation of user-defined free store management into C++ has made assignment to “this” an anachronism. Therefore, by default it is invalid to assign to this within a class member function; that is, GNU C++ treats “this” in a member function of class X as a non-lvalue of type “X *”. However, for backwards compatibility, you can make it valid with “-fthis-is-variable”.
Use “thunks” to implement the virtual function dispatch table (“vtable”). The traditional (cfront-style) approach to implementing vtables was to store a pointer to the function and two offsets for adjusting the “this” pointer at the call site. Newer implementations store a single pointer to a “thunk” function that does any necessary adjustment and then calls the target function.
This option also enables a heuristic for controlling emission of vtables; if a class has any non-inline virtual functions, the vtable will be emitted in the translation unit containing the first one of those.
Set the maximum instantiation depth for template classes to n. A limit on the template instantiation depth is needed to detect endless recursions during template class instantiation. ANSI/ISO C++ conforming programs must not rely on a maximum depth greater than 17.
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 the C++ library.)
For C++ programs (in addition to the effects that apply to both C and C++), this has the same effect as “-fthis-is-variable”. See Section 1.4.
In addition, these optimization, warning, and code generation options have meanings only for C++ programs:
Do not assume “inline” for functions defined inside a class scope. See Section 1.8.
Warnings that apply only to C++ programs. See Section 1.6.
Warn about violation of some style rules from Effective C++ by Scott Myers.
Control how virtual function definitions are used, in a fashion compatible with cfront 1.x. See Section 1.14.