[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The GNU compiler provides these extensions to the C++ language (and you
can also use most of the C language extensions in your C++ programs). If you
want to write code that checks whether these features are available, you can
test for the GNU compiler the same way as for C programs: check for a
predefined macro __GNUC__
. You can also use __GNUG__
to
test specifically for GNU C++ (see section `Predefined Macros' in The GNU C Preprocessor).
6.1 Minimum and Maximum Operators in C++ C++ Minimum and maximum operators. 6.2 When is a Volatile Object Accessed? What constitutes an access to a volatile object. 6.3 Restricting Pointer Aliasing C99 restricted pointers and references. 6.4 Vague Linkage Where G++ puts inlines, vtables and such. 6.5 #pragma interface and implementation You can use a single C++ header file for both declarations and definitions. 6.6 Where's the Template? Methods for ensuring that exactly one copy of each needed template instantiation is emitted. 6.7 Extracting the function pointer from a bound pointer to member function You can extract a function pointer to the method denoted by a `->*' or `.*' expression. 6.8 C++-Specific Variable, Function, and Type Attributes Variable, function, and type attributes for C++ only. 6.9 Strong Using Strong using-directives for namespace composition. 6.10 Offsetof Special syntax for implementing offsetof
.6.11 Java Exceptions Tweaking exception handling to work with Java. 6.12 Deprecated Features Things will disappear from g++. 6.13 Backwards Compatibility Compatibilities with earlier definitions of C++.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
It is very convenient to have operators which return the "minimum" or the "maximum" of two arguments. In GNU C++ (but not in GNU C),
a <? b
a >? b
These operations are not primitive in ordinary C++, since you can use a macro to return the minimum of two things in C++, as in the following example.
#define MIN(X,Y) ((X) < (Y) ? : (X) : (Y)) |
You might then use `int min = MIN (i, j);' to set min to the minimum value of variables i and j.
However, side effects in X
or Y
may cause unintended
behavior. For example, MIN (i++, j++)
will fail, incrementing
the smaller counter twice. The GNU C typeof
extension allows you
to write safe macros that avoid this kind of problem (see section 5.6 Referring to a Type with typeof
).
However, writing MIN
and MAX
as macros also forces you to
use function-call notation for a fundamental arithmetic operation.
Using GNU C++ extensions, you can write `int min = i <? j;'
instead.
Since <?
and >?
are built into the compiler, they properly
handle expressions with side-effects; `int min = i++ <? j++;'
works correctly.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Both the C and C++ standard have the concept of volatile objects. These are normally accessed by pointers and used for accessing hardware. The standards encourage compilers to refrain from optimizations concerning accesses to volatile objects that it might perform on non-volatile objects. The C standard leaves it implementation defined as to what constitutes a volatile access. The C++ standard omits to specify this, except to say that C++ should behave in a similar manner to C with respect to volatiles, where possible. The minimum either standard specifies is that at a sequence point all previous accesses to volatile objects have stabilized and no subsequent accesses have occurred. Thus an implementation is free to reorder and combine volatile accesses which occur between sequence points, but cannot do so for accesses across a sequence point. The use of volatiles does not allow you to violate the restriction on updating objects multiple times within a sequence point.
In most expressions, it is intuitively obvious what is a read and what is a write. For instance
volatile int *dst = somevalue; volatile int *src = someothervalue; *dst = *src; |
will cause a read of the volatile object pointed to by src and stores the
value into the volatile object pointed to by dst. There is no
guarantee that these reads and writes are atomic, especially for objects
larger than int
.
Less obvious expressions are where something which looks like an access is used in a void context. An example would be,
volatile int *src = somevalue; *src; |
With C, such expressions are rvalues, and as rvalues cause a read of the object, GCC interprets this as a read of the volatile being pointed to. The C++ standard specifies that such expressions do not undergo lvalue to rvalue conversion, and that the type of the dereferenced object may be incomplete. The C++ standard does not specify explicitly that it is this lvalue to rvalue conversion which is responsible for causing an access. However, there is reason to believe that it is, because otherwise certain simple expressions become undefined. However, because it would surprise most programmers, G++ treats dereferencing a pointer to volatile object of complete type in a void context as a read of the object. When the object has incomplete type, G++ issues a warning.
struct S; struct T {int m;}; volatile S *ptr1 = somevalue; volatile T *ptr2 = somevalue; *ptr1; *ptr2; |
In this example, a warning is issued for *ptr1
, and *ptr2
causes a read of the object pointed to. If you wish to force an error on
the first case, you must force a conversion to rvalue with, for instance
a static cast, static_cast<S>(*ptr1)
.
When using a reference to volatile, G++ does not treat equivalent expressions as accesses to volatiles, but instead issues a warning that no volatile is accessed. The rationale for this is that otherwise it becomes difficult to determine where volatile access occur, and not possible to ignore the return value from functions returning volatile references. Again, if you wish to force a read, cast the reference to an rvalue.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As with the C front end, G++ understands the C99 feature of restricted pointers,
specified with the __restrict__
, or __restrict
type
qualifier. Because you cannot compile C++ by specifying the `-std=c99'
language flag, restrict
is not a keyword in C++.
In addition to allowing restricted pointers, you can specify restricted references, which indicate that the reference is not aliased in the local context.
void fn (int *__restrict__ rptr, int &__restrict__ rref) { /* ... */ } |
In the body of fn
, rptr points to an unaliased integer and
rref refers to a (different) unaliased integer.
You may also specify whether a member function's this pointer is
unaliased by using __restrict__
as a member function qualifier.
void T::fn () __restrict__ { /* ... */ } |
Within the body of T::fn
, this will have the effective
definition T *__restrict__ const this
. Notice that the
interpretation of a __restrict__
member function qualifier is
different to that of const
or volatile
qualifier, in that it
is applied to the pointer rather than the object. This is consistent with
other compilers which implement restricted pointers.
As with all outermost parameter qualifiers, __restrict__
is
ignored in function definition matching. This means you only need to
specify __restrict__
in a function definition, rather than
in a function prototype as well.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are several constructs in C++ which require space in the object file but are not clearly tied to a single translation unit. We say that these constructs have "vague linkage". Typically such constructs are emitted wherever they are needed, though sometimes we can be more clever.
Local static variables and string constants used in an inline function are also considered to have vague linkage, since they must be shared between all inlined and out-of-line instances of the function.
Note: If the chosen key method is later defined as inline, the vtable will still be emitted in every translation unit which defines it. Make sure that any inline virtuals are declared inline in the class body, even if they are not defined there.
When used with GNU ld version 2.8 or later on an ELF system such as GNU/Linux or Solaris 2, or on Microsoft Windows, duplicate copies of these constructs will be discarded at link time. This is known as COMDAT support.
On targets that don't support COMDAT, but do support weak symbols, GCC will use them. This way one copy will override all the others, but the unused copies will still take up space in the executable.
For targets which do not support either COMDAT or weak symbols, most entities with vague linkage will be emitted as local symbols to avoid duplicate definition errors from the linker. This will not happen for local statics in inlines, however, as having multiple copies will almost certainly break things.
See section Declarations and Definitions in One Header, for another way to control placement of these constructs.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
#pragma interface
and #pragma implementation
provide the
user with a way of explicitly directing the compiler to emit entities
with vague linkage (and debugging information) in a particular
translation unit.
Note: As of GCC 2.7.2, these #pragma
s are not useful in
most cases, because of COMDAT support and the "key method" heuristic
mentioned in 6.4 Vague Linkage. Using them can actually cause your
program to grow due to unnecesary out-of-line copies of inline
functions. Currently the only benefit of these #pragma
s is
reduced duplication of debugging information, and that should be
addressed soon on DWARF 2 targets with the use of COMDAT sections.
#pragma interface
#pragma interface "subdir/objects.h"
The second form of this directive is useful for the case where you have multiple headers with the same name in different directories. If you use this form, you must specify the same string to `#pragma implementation'.
#pragma implementation
#pragma implementation "objects.h"
If you use `#pragma implementation' with no argument, it applies to an include file with the same basename(4) as your source file. For example, in `allclass.cc', giving just `#pragma implementation' by itself is equivalent to `#pragma implementation "allclass.h"'.
In versions of GNU C++ prior to 2.6.0 `allclass.h' was treated as an implementation file whenever you would include it from `allclass.cc' even if you never specified `#pragma implementation'. This was deemed to be more trouble than it was worth, however, and disabled.
Use the string argument if you want a single implementation file to include code from multiple header files. (You must also use `#include' to include the header file; `#pragma implementation' only specifies how to use the file--it doesn't actually include it.)
There is no way to split up the contents of a single header file into multiple implementation files.
`#pragma implementation' and `#pragma interface' also have an effect on function inlining.
If you define a class in a header file marked with `#pragma
interface', the effect on an inline function defined in that class is
similar to an explicit extern
declaration--the compiler emits
no code at all to define an independent version of the function. Its
definition is used only for inlining with its callers.
Conversely, when you include the same header file in a main source file that declares it as `#pragma implementation', the compiler emits code for the function itself; this defines a version of the function that can be found via pointers (or by callers compiled without inlining). If all calls to the function can be inlined, you can avoid emitting the function by compiling with `-fno-implement-inlines'. If any calls were not inlined, you will get linker errors.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
C++ templates are the first language feature to require more intelligence from the environment than one usually finds on a UNIX system. Somehow the compiler and linker have to make sure that each template instance occurs exactly once in the executable if it is needed, and not at all otherwise. There are two basic approaches to this problem, which are referred to as the Borland model and the Cfront model.
When used with GNU ld version 2.8 or later on an ELF system such as GNU/Linux or Solaris 2, or on Microsoft Windows, G++ supports the Borland model. On other systems, G++ implements neither automatic model.
A future version of G++ will support a hybrid model whereby the compiler will emit any instantiations for which the template definition is included in the compile, and store template definitions and instantiation context information into the object file for the rest. The link wrapper will extract that information as necessary and invoke the compiler to produce the remaining instantiations. The linker will then combine duplicate instantiations.
In the mean time, you have the following options for dealing with template instantiations:
This is your best option for application code written for the Borland
model, as it will just work. Code written for the Cfront model will
need to be modified so that the template definitions are available at
one or more points of instantiation; usually this is as simple as adding
#include <tmethods.cc>
to the end of each template header.
For library code, if you want the library to provide all of the template instantiations it needs, just try to link all of its object files together; the link will fail, but cause the instantiations to be generated as a side effect. Be warned, however, that this may cause conflicts if multiple libraries try to provide the same instantiations. For greater control, use explicit instantiation as described in the next option.
#include "Foo.h" #include "Foo.cc" template class Foo<int>; template ostream& operator << (ostream&, const Foo<int>&); |
for each of the instances you need, and create a template instantiation library from those.
If you are using Cfront-model code, you can probably get away with not using `-fno-implicit-templates' when compiling files that don't `#include' the member template definitions.
If you use one big file to do the instantiations, you may want to compile it without `-fno-implicit-templates' so you get all of the instances required by your explicit instantiations (but not by any other files) without having to specify them as well.
G++ has extended the template instantiation syntax given in the ISO
standard to allow forward declaration of explicit instantiations
(with extern
), instantiation of the compiler support data for a
template class (i.e. the vtable) without instantiating any of its
members (with inline
), and instantiation of only the static data
members of a template class, without the support data or member
functions (with (static
):
extern template int max (int, int); inline template class Foo<int>; static template class Foo<int>; |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In C++, pointer to member functions (PMFs) are implemented using a wide pointer of sorts to handle all the possible call mechanisms; the PMF needs to store information about how to adjust the `this' pointer, and if the function pointed to is virtual, where to find the vtable, and where in the vtable to look for the member function. If you are using PMFs in an inner loop, you should really reconsider that decision. If that is not an option, you can extract the pointer to the function that would be called for a given object/PMF pair and call it directly inside the inner loop, to save a bit of time.
Note that you will still be paying the penalty for the call through a function pointer; on most modern architectures, such a call defeats the branch prediction features of the CPU. This is also true of normal virtual function calls.
The syntax for this extension is
extern A a; extern int (A::*fp)(); typedef int (*fptr)(A *); fptr p = (fptr)(a.*fp); |
For PMF constants (i.e. expressions of the form `&Klasse::Member'), no object is needed to obtain the address of the function. They can be converted to function pointers directly:
fptr p1 = (fptr)(&A::foo); |
You must specify `-Wno-pmf-conversions' to use this extension.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some attributes only make sense for C++ programs.
init_priority (priority)
In Standard C++, objects defined at namespace scope are guaranteed to be
initialized in an order in strict accordance with that of their definitions
in a given translation unit. No guarantee is made for initializations
across translation units. However, GNU C++ allows users to control the
order of initialization of objects defined at namespace scope with the
init_priority
attribute by specifying a relative priority,
a constant integral expression currently bounded between 101 and 65535
inclusive. Lower numbers indicate a higher priority.
In the following example, A
would normally be created before
B
, but the init_priority
attribute has reversed that order:
Some_Class A __attribute__ ((init_priority (2000))); Some_Class B __attribute__ ((init_priority (543))); |
Note that the particular values of priority do not matter; only their relative ordering.
java_interface
This type attribute informs C++ that the class is a Java interface. It may
only be applied to classes declared within an extern "Java"
block.
Calls to methods declared in this interface will be dispatched using GCJ's
interface table mechanism, instead of regular virtual table dispatch.
See also See section 6.9 Strong Using.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Caution: The semantics of this extension are not fully defined. Users should refrain from using this extension as its semantics may change subtly over time. It is possible that this extension wil be removed in future versions of G++.
A using-directive with __attribute ((strong))
is stronger
than a normal using-directive in two ways:
This is useful for composing a namespace transparently from implementation namespaces. For example:
namespace std { namespace debug { template <class T> struct A { }; } using namespace debug __attribute ((__strong__)); template <> struct A<int> { }; // ok to specialize template <class T> void f (A<T>); } int main() { f (std::A<float>()); // lookup finds std::f f (std::A<int>()); } |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
G++ uses a syntactic extension to implement the offsetof
macro.
In particular:
__offsetof__ (expression) |
is equivalent to the parenthesized expression, except that the
expression is considered an integral constant expression even if it
contains certain operators that are not normally permitted in an
integral constant expression. Users should never use
__offsetof__
directly; the only valid use of
__offsetof__
is to implement the offsetof
macro in
<stddef.h>
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Java language uses a slightly different exception handling model from C++. Normally, GNU C++ will automatically detect when you are writing C++ code that uses Java exceptions, and handle them appropriately. However, if C++ code only needs to execute destructors when Java exceptions are thrown through it, GCC will guess incorrectly. Sample problematic code is:
struct S { ~S(); }; extern void bar(); // is written in Java, and may throw exceptions void foo() { S s; bar(); } |
The usual effect of an incorrect guess is a link failure, complaining of a missing routine called `__gxx_personality_v0'.
You can inform the compiler that Java exceptions are to be used in a translation unit, irrespective of what it might think, by writing `#pragma GCC java_exceptions' at the head of the file. This `#pragma' must appear before any functions that throw or catch exceptions, or run destructors when exceptions are thrown through them.
You cannot mix Java and C++ exceptions in the same translation unit. It is believed to be safe to throw a C++ exception from one file through another file compiled for the Java exception model, or vice versa, but there may be bugs in this area.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In the past, the GNU C++ compiler was extended to experiment with new features, at a time when the C++ language was still evolving. Now that the C++ standard is complete, some of those features are superseded by superior alternatives. Using the old features might cause a warning in some cases that the feature will be dropped in the future. In other cases, the feature might be gone already.
While the list below is not exhaustive, it documents some of the options that are now deprecated:
-fexternal-templates
-falt-external-templates
-fstrict-prototype
-fno-strict-prototype
The named return value extension has been deprecated, and is now removed from G++.
The use of initializer lists with new expressions has been deprecated, and is now removed from G++.
Floating and complex non-type template parameters have been deprecated, and are now removed from G++.
The implicit typename extension has been deprecated and is now removed from G++.
The use of default arguments in function pointers, function typedefs and and other places where they are not permitted by the standard is deprecated and will be removed from a future version of G++.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Now that there is a definitive ISO standard C++, G++ has a specification to adhere to. The C++ language evolved over time, and features that used to be acceptable in previous drafts of the standard, such as the ARM [Annotated C++ Reference Manual], are no longer accepted. In order to allow compilation of C++ written to such drafts, G++ contains some backwards compatibilities. All such backwards compatibility features are liable to disappear in future versions of G++. They should be considered deprecated See section 6.12 Deprecated Features.
For scope
Implicit C language
extern "C" {...}
scope to set the language. On such systems, all header files are
implicitly scoped inside a C language scope. Also, an empty prototype
()
will be treated as an unspecified number of arguments, rather
than no arguments, as C++ demands.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |