-@c Copyright (C) 1988,89,92,93,94,96,99 Free Software Foundation, Inc.
+@c Copyright (C) 1988,89,92,93,94,96,98, 99 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
function.
* Return Address:: Getting the return or frame address of a function.
* Deprecated Features:: Things might disappear from g++.
+* Other Builtins:: Other built-in functions.
@end menu
@end ifclear
The labels within the interpreter function can be stored in the
threaded code for super-fast dispatching.
-You can use this mechanism to jump to code in a different function. If
-you do that, totally unpredictable things will happen. The best way to
+You may not use this mechanism to jump to code in a different function.
+If you do that, totally unpredictable things will happen. The best way to
avoid this is to store the label address only in automatic variables and
never pass it as an argument.
+An alternate way to write the above example is
+
+@example
+static const int array[] = @{ &&foo - &&foo, &&bar - &&foo, &&hack - &&foo @};
+goto *(&&foo + array[i]);
+@end example
+
+@noindent
+This is more friendly to code living in shared libraries, as it reduces
+the number of dynamic relocations that are needed, and by consequence,
+allows the data to be read-only.
+
@node Nested Functions
@section Nested Functions
@cindex nested functions
@node Hex Floats
@section Hex Floats
@cindex hex floats
-GNU CC recognizes floating-point numbers written not only in the usual
+
+GNU CC recognizes floating-point numbers writen not only in the usual
decimal notation, such as @code{1.55e1}, but also numbers such as
@code{0x1.fp3} written in hexadecimal format. In that format the
@code{0x} hex introducer and the @code{p} or @code{P} exponent field are
@cindex functions that never return
@cindex functions that have no side effects
@cindex functions in arbitrary sections
+@cindex functions that bahave like malloc
@cindex @code{volatile} applied to function
@cindex @code{const} applied to function
@cindex functions with @code{printf}, @code{scanf} or @code{strftime} style arguments
The keyword @code{__attribute__} allows you to specify special
attributes when making a declaration. This keyword is followed by an
-attribute specification inside double parentheses. Nine attributes,
+attribute specification inside double parentheses. Ten attributes,
@code{noreturn}, @code{const}, @code{format},
-@code{no_instrument_function}, @code{section},
-@code{constructor}, @code{destructor}, @code{unused} and @code{weak} are
+@code{no_instrument_function}, @code{section}, @code{constructor},
+@code{destructor}, @code{unused}, @code{weak} and @code{malloc} are
currently defined for functions. Other attributes, including
@code{section} are supported for variables declarations (@pxref{Variable
Attributes}) and for types (@pxref{Type Attributes}).
for ELF targets, and also for a.out targets when using the GNU assembler
and linker.
+@item malloc
+@cindex @code{malloc} attribute
+The @code{malloc} attribute is used to tell the compiler that a function
+may be treated as if it were the malloc function. The compiler assumes
+that calls to malloc result in a pointers that cannot alias anything.
+This will often improve optimization.
+
@item alias ("target")
@cindex @code{alias} attribute
The @code{alias} attribute causes the declaration to be emitted as an
@item no_check_memory_usage
@cindex @code{no_check_memory_usage} function attribute
-If @samp{-fcheck-memory-usage} is given, calls to support routines will
-be generated before most memory accesses, to permit support code to
-record usage and detect uses of uninitialized or unallocated storage.
-Since the compiler cannot handle them properly, @code{asm} statements
-are not allowed. Declaring a function with this attribute disables the
+The @code{no_check_memory_usage} attribute causes GNU CC to omit checks
+of memory references when it generates code for that function. Normally
+if you specify @samp{-fcheck-memory-usage} (see @pxref{Code Gen
+Options}), GNU CC generates calls to support routines before most memory
+accesses to permit support code to record usage and detect uses of
+uninitialized or unallocated storage. Since GNU CC cannot handle
+@code{asm} statements properly they are not allowed in such functions.
+If you declare a function with this attribute, GNU CC will not generate
memory checking code for that function, permitting the use of @code{asm}
-statements without requiring separate compilation with different
-options, and allowing you to write support routines of your own if you
-wish, without getting infinite recursion if they get compiled with this
-option.
+statements without having to compile that function with different
+options. This also allows you to write support routines of your own if
+you wish, without getting infinite recursion if they get compiled with
+@code{-fcheck-memory-usage}.
@item regparm (@var{number})
@cindex functions that are passed arguments in registers on the 386
If you need to map the entire contents of a module to a particular
section, consider using the facilities of the linker instead.
+@item shared
+@cindex @code{shared} variable attribute
+On Windows NT, in addition to nputting variable definitions in a named
+section, the section can also be shared among all running copies of an
+executable or DLL. For example, this small program defines shared data
+by putting it in a named section "shared" and marking the section
+shareable:
+
+@smallexample
+int foo __attribute__((section ("shared"), shared)) = 0;
+
+int
+main()
+@{
+ /* Read and write foo. All running copies see the same value. */
+ return 0;
+@}
+@end smallexample
+
+@noindent
+You may only use the @code{shared} attribute along with @code{section}
+attribute with a fully initialized global definition because of the way
+linkers work. See @code{section} attribute for more information.
+
+The @code{shared} attribute is only available on Windows NT.
+
@item transparent_union
This attribute, attached to a function parameter which is a union, means
that the corresponding argument may have the type of any union member,
: "r0", "r1", "r2", "r3", "r4", "r5");
@end example
-It is an error for a clobber description to overlap an input or output
-operand (for example, an operand describing a register class with one
-member, mentioned in the clobber list). Most notably, it is invalid to
-describe that an input operand is modified, but unused as output. It has
-to be specified as an input and output operand anyway. Note that if there
-are only unused output operands, you will then also need to specify
-@code{volatile} for the @code{asm} construct, as described below.
+You may not write a clobber description in a way that overlaps with an
+input or output operand. For example, you may not have an operand
+describing a register class with one member if you mention that register
+in the clobber list. There is no way for you to specify that an input
+operand is modified without also specifying it as an output
+operand. Note that if all the output operands you specify are for this
+purpose (and hence unused), you will then also need to specify
+@code{volatile} for the @code{asm} construct, as described below, to
+prevent GNU CC from deleting the @code{asm} statement as unused.
If you refer to a particular hardware register from the assembler code,
you will probably have to list the register after the third colon to
@end example
@findex __extension__
-@samp{-pedantic} causes warnings for many GNU C extensions. You can
+@samp{-pedantic} and other options cause warnings for many GNU C extensions.
+You can
prevent such warnings within one expression by writing
@code{__extension__} before the expression. @code{__extension__} has no
effect aside from this.
@node Function Names
@section Function Names as Strings
-GNU CC predefines two string variables to be the name of the current function.
-The variable @code{__FUNCTION__} is the name of the function as it appears
-in the source. The variable @code{__PRETTY_FUNCTION__} is the name of
-the function pretty printed in a language specific fashion.
+GNU CC predefines two magic identifiers to hold the name of the current
+function. The identifier @code{__FUNCTION__} holds the name of the function
+as it appears in the source. The identifier @code{__PRETTY_FUNCTION__}
+holds the name of the function pretty printed in a language specific
+fashion.
These names are always the same in a C function, but in a C++ function
they may be different. For example, this program:
__PRETTY_FUNCTION__ = int a::sub (int)
@end smallexample
-These names are not macros: they are predefined string variables.
-For example, @samp{#ifdef __FUNCTION__} does not have any special
+The compiler automagically replaces the identifiers with a string
+literal containing the appropriate name. Thus, they are neither
+preprocessor macros, like @code{__FILE__} and @code{__LINE__}, nor
+variables. This means that they catenate with other string literals, and
+that they can be used to initialize char arrays. For example
+
+@smallexample
+char here[] = "Function " __FUNCTION__ " in " __FILE__;
+@end smallexample
+
+On the other hand, @samp{#ifdef __FUNCTION__} does not have any special
meaning inside a function, since the preprocessor does not do anything
special with the identifier @code{__FUNCTION__}.
+GNU CC also supports the magic word @code{__func__}, defined by the
+draft standard for C-99:
+
+@display
+The identifier @code{__func__} is implicitly declared by the translator
+as if, immediately following the opening brace of each function
+definition, the declaration
+
+@smallexample
+static const char __func__[] = "function-name";
+@end smallexample
+
+appeared, where function-name is the name of the lexically-enclosing
+function. This name is the unadorned name of the function.
+@end display
+
+By this definition, @code{__func__} is a variable, not a string literal.
+In particular, @code{__func__} does not catenate with other string
+literals.
+
+In @code{C++}, @code{__FUNCTION__} and @code{__PRETTY_FUNCTION__} are
+variables, declared in the same way as @code{__func__}.
+
@node Return Address
@section Getting the Return or Frame Address of a Function
standard C library. These will always be treated as having the same
meaning as the C library function even if you specify the
@samp{-fno-builtin} (@pxref{C Dialect Options}) option. These functions
-correspond to the C library functions @code{alloca}, @code{ffs},
-@code{abs}, @code{fabsf}, @code{fabs}, @code{fabsl}, @code{labs},
-@code{memcpy}, @code{memcmp}, @code{strcmp}, @code{strcpy},
-@code{strlen}, @code{sqrtf}, @code{sqrt}, @code{sqrtl}, @code{sinf},
-@code{sin}, @code{sinl}, @code{cosf}, @code{cos}, and @code{cosl}.
+correspond to the C library functions @code{abort}, @code{abs},
+@code{alloca}, @code{cos}, @code{cosf}, @code{cosl}, @code{exit},
+@code{_exit}, @code{fabs}, @code{fabsf}, @code{fabsl}, @code{ffs},
+@code{labs}, @code{memcmp}, @code{memcpy}, @code{memset}, @code{sin},
+@code{sinf}, @code{sinl}, @code{sqrt}, @code{sqrtf}, @code{sqrtl},
+@code{strcmp}, @code{strcpy}, and @code{strlen}.
@findex __builtin_constant_p
You can use the builtin function @code{__builtin_constant_p} to
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 superceded by
+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.
@menu
* Naming Results:: Giving a name to C++ function return values.
* Min and Max:: C++ Minimum and maximum operators.
-* Destructors and Goto:: Goto is safe to use in C++ even when destructors
- are needed.
+* Volatiles:: What constitutes an access to a volatile object.
+* Restricted Pointers:: C9X restricted pointers and references.
* C++ Interface:: You can use a single C++ header file for both
declarations and definitions.
* Template Instantiation:: Methods for ensuring that exactly one copy of
each needed template instantiation is emitted.
* Bound member functions:: You can extract a function pointer to the
method denoted by a @samp{->*} or @samp{.*} expression.
-* C++ Signatures:: You can specify abstract types to get subtype
- polymorphism independent from inheritance.
-
@end menu
@node Naming Results
handle expressions with side-effects; @w{@samp{int min = i++ <? j++;}}
works correctly.
-@node Destructors and Goto
-@section @code{goto} and Destructors in GNU C++
+@node Volatiles
+@section When is a Volatile Object Accessed?
+@cindex accessing volatiles
+@cindex volatile read
+@cindex volatile write
+@cindex volatile access
+
+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 on
+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 access 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
+
+@example
+volatile int *dst = <somevalue>;
+volatile int *src = <someothervalue>;
+*dst = *src;
+@end example
-@cindex @code{goto} in C++
-@cindex destructors vs @code{goto}
-In C++ programs, you can safely use the @code{goto} statement. When you
-use it to exit a block which contains aggregates requiring destructors,
-the destructors will run before the @code{goto} transfers control.
+@noindent
+will cause a read of the volatile object pointed to by @var{src} and stores the
+value into the volatile object pointed to by @var{dst}. There is no
+guarantee that these reads and writes are atomic, especially for objects
+larger than @code{int}.
+
+Less obvious expressions are where something which looks like an access
+is used in a void context. An example would be,
+
+@example
+volatile int *src = <somevalue>;
+*src;
+@end example
+
+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.
+
+@example
+struct S;
+struct T @{int m;@};
+volatile S *ptr1 = <somevalue>;
+volatile T *ptr2 = <somevalue>;
+*ptr1;
+*ptr2;
+@end example
+
+In this example, a warning is issued for @code{*ptr1}, and @code{*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, @code{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.
+
+@node Restricted Pointers
+@section Restricting Pointer Aliasing
+@cindex restricted pointers
+@cindex restricted references
+@cindex restricted this pointer
+
+As with gcc, g++ understands the C9X proposal of restricted pointers,
+specified with the @code{__restrict__}, or @code{__restrict} type
+qualifier. Because you cannot compile C++ by specifying the -flang-isoc9x
+language flag, @code{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.
+
+@example
+void fn (int *__restrict__ rptr, int &__restrict__ rref)
+@{
+ @dots{}
+@}
+@end example
+
+@noindent
+In the body of @code{fn}, @var{rptr} points to an unaliased integer and
+@var{rref} refers to a (different) unaliased integer.
+
+You may also specify whether a member function's @var{this} pointer is
+unaliased by using @code{__restrict__} as a member function qualifier.
-@cindex constructors vs @code{goto}
-The compiler still forbids using @code{goto} to @emph{enter} a scope
-that requires constructors.
+@example
+void T::fn () __restrict__
+@{
+ @dots{}
+@}
+@end example
+
+@noindent
+Within the body of @code{T::fn}, @var{this} will have the effective
+definition @code{T *__restrict__ const this}. Notice that the
+interpretation of a @code{__restrict__} member function qualifier is
+different to that of @code{const} or @code{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, @code{__restrict__} is
+ignored in function definition matching. This means you only need to
+specify @code{__restrict__} in a function definition, rather than
+in a function prototype as well.
@node C++ Interface
@section Declarations and Definitions in One Header
fptr p = (fptr)(a.*fp);
@end example
-You must specify @samp{-Wno-pmf-conversions} to use this extension.
-
-@node C++ Signatures
-@section Type Abstraction using Signatures
-
-@findex signature
-@cindex type abstraction, C++
-@cindex C++ type abstraction
-@cindex subtype polymorphism, C++
-@cindex C++ subtype polymorphism
-@cindex signatures, C++
-@cindex C++ signatures
-
-In GNU C++, you can use the keyword @code{signature} to define a
-completely abstract class interface as a datatype. You can connect this
-abstraction with actual classes using signature pointers. If you want
-to use signatures, run the GNU compiler with the
-@samp{-fhandle-signatures} command-line option. (With this option, the
-compiler reserves a second keyword @code{sigof} as well, for a future
-extension.)
-
-Roughly, signatures are type abstractions or interfaces of classes.
-Some other languages have similar facilities. C++ signatures are
-related to ML's signatures, Haskell's type classes, definition modules
-in Modula-2, interface modules in Modula-3, abstract types in Emerald,
-type modules in Trellis/Owl, categories in Scratchpad II, and types in
-POOL-I. For a more detailed discussion of signatures, see
-@cite{Signatures: A Language Extension for Improving Type Abstraction and
-Subtype Polymorphism in C++}
-by @w{Gerald} Baumgartner and Vincent F. Russo (Tech report
-CSD--TR--95--051, Dept. of Computer Sciences, Purdue University,
-August 1995, a slightly improved version appeared in
-@emph{Software---Practice & Experience}, @b{25}(8), pp. 863--889,
-August 1995). You can get the tech report by anonymous FTP from
-@code{ftp.cs.purdue.edu} in @file{pub/gb/Signature-design.ps.gz}.
-
-Syntactically, a signature declaration is a collection of
-member function declarations and nested type declarations.
-For example, this signature declaration defines a new abstract type
-@code{S} with member functions @samp{int foo ()} and @samp{int bar (int)}:
-
-@example
-signature S
-@{
- int foo ();
- int bar (int);
-@};
-@end example
-
-Since signature types do not include implementation definitions, you
-cannot write an instance of a signature directly. Instead, you can
-define a pointer to any class that contains the required interfaces as a
-@dfn{signature pointer}. Such a class @dfn{implements} the signature
-type.
-@c Eventually signature references should work too.
-
-To use a class as an implementation of @code{S}, you must ensure that
-the class has public member functions @samp{int foo ()} and @samp{int
-bar (int)}. The class can have other member functions as well, public
-or not; as long as it offers what's declared in the signature, it is
-suitable as an implementation of that signature type.
-
-For example, suppose that @code{C} is a class that meets the
-requirements of signature @code{S} (@code{C} @dfn{conforms to}
-@code{S}). Then
+For PMF constants (i.e. expressions of the form @samp{&Klasse::Member}),
+no object is needed to obtain the address of the function. They can be
+converted to function pointers directly:
@example
-C obj;
-S * p = &obj;
+fptr p1 = (fptr)(&A::foo);
@end example
-@noindent
-defines a signature pointer @code{p} and initializes it to point to an
-object of type @code{C}.
-The member function call @w{@samp{int i = p->foo ();}}
-executes @samp{obj.foo ()}.
-
-@cindex @code{signature} in C++, advantages
-Abstract virtual classes provide somewhat similar facilities in standard
-C++. There are two main advantages to using signatures instead:
-
-@enumerate
-@item
-Subtyping becomes independent from inheritance. A class or signature
-type @code{T} is a subtype of a signature type @code{S} independent of
-any inheritance hierarchy as long as all the member functions declared
-in @code{S} are also found in @code{T}. So you can define a subtype
-hierarchy that is completely independent from any inheritance
-(implementation) hierarchy, instead of being forced to use types that
-mirror the class inheritance hierarchy.
-
-@item
-Signatures allow you to work with existing class hierarchies as
-implementations of a signature type. If those class hierarchies are
-only available in compiled form, you're out of luck with abstract virtual
-classes, since an abstract virtual class cannot be retrofitted on top of
-existing class hierarchies. So you would be required to write interface
-classes as subtypes of the abstract virtual class.
-@end enumerate
-
-@cindex default implementation, signature member function
-@cindex signature member function default implementation
-There is one more detail about signatures. A signature declaration can
-contain member function @emph{definitions} as well as member function
-declarations. A signature member function with a full definition is
-called a @emph{default implementation}; classes need not contain that
-particular interface in order to conform. For example, a
-class @code{C} can conform to the signature
-
-@example
-signature T
-@{
- int f (int);
- int f0 () @{ return f (0); @};
-@};
-@end example
+You must specify @samp{-Wno-pmf-conversions} to use this extension.
-@noindent
-whether or not @code{C} implements the member function @samp{int f0 ()}.
-If you define @code{C::f0}, that definition takes precedence;
-otherwise, the default implementation @code{S::f0} applies.
-
-@ignore
-There will be more support for signatures in the future.
-Add to this doc as the implementation grows.
-In particular, the following features are planned but not yet
-implemented:
-@itemize @bullet
-@item signature references,
-@item signature inheritance,
-@item the @code{sigof} construct for extracting the signature information
- of a class,
-@item views for renaming member functions when matching a class type
- with a signature type,
-@item specifying exceptions with signature member functions, and
-@item signature templates.
-@end itemize
-This list is roughly in the order in which we intend to implement
-them. Watch this space for updates.
-@end ignore
OSDN Git Service
