851 lines
45 KiB
HTML
851 lines
45 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on March, 17 2001 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>Using and Porting the GNU Compiler Collection (GCC): C++ Extensions</TITLE>
|
|
|
|
<META NAME="description" CONTENT="Using and Porting the GNU Compiler Collection (GCC): C++ Extensions">
|
|
<META NAME="keywords" CONTENT="Using and Porting the GNU Compiler Collection (GCC): C++ Extensions">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC105"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_4.html#SEC104" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC104"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC106" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC106"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 5. Extensions to the C++ Language </H1>
|
|
<!--docid::SEC105::-->
|
|
<P>
|
|
|
|
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 <CODE>__GNUC__</CODE>. You can also use <CODE>__GNUG__</CODE> to
|
|
test specifically for GNU C++ (see section `Standard Predefined Macros' in <CITE>The C Preprocessor</CITE>).
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_5.html#SEC106" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC106">5.1 Named Return Values in C++</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Giving a name to C++ function return values.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_5.html#SEC107" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC107">5.2 Minimum and Maximum Operators in C++</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">C++ Minimum and maximum operators.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_5.html#SEC108" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC108">5.3 <CODE>goto</CODE> and Destructors in GNU C++</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Goto is safe to use in C++ even when destructors
|
|
are needed.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_5.html#SEC109" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC109">5.4 Declarations and Definitions in One Header</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">You can use a single C++ header file for both
|
|
declarations and definitions.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_5.html#SEC110" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC110">5.5 Where's the Template?</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Methods for ensuring that exactly one copy of
|
|
each needed template instantiation is emitted.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_5.html#SEC111" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC111">5.6 Extracting the function pointer from a bound pointer to member function</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">You can extract a function pointer to the
|
|
method denoted by a <SAMP>`->*'</SAMP> or <SAMP>`.*'</SAMP> expression.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_5.html#SEC112" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112">5.7 Type Abstraction using Signatures</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">You can specify abstract types to get subtype
|
|
polymorphism independent from inheritance.</TD></TR>
|
|
</TABLE>
|
|
|
|
<br>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Naming Results"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC106"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC107" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC107"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.1 Named Return Values in C++ </H2>
|
|
<!--docid::SEC106::-->
|
|
<P>
|
|
|
|
<A NAME="IDX323"></A>
|
|
<A NAME="IDX324"></A>
|
|
<A NAME="IDX325"></A>
|
|
<A NAME="IDX326"></A>
|
|
GNU C++ extends the function-definition syntax to allow you to specify a
|
|
name for the result of a function outside the body of the definition, in
|
|
C++ programs:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre><VAR>type</VAR>
|
|
<VAR>functionname</VAR> (<VAR>args</VAR>) return <VAR>resultname</VAR>;
|
|
{
|
|
<small>...</small>
|
|
<VAR>body</VAR>
|
|
<small>...</small>
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You can use this feature to avoid an extra constructor call when
|
|
a function result has a class type. For example, consider a function
|
|
<CODE>m</CODE>, declared as <SAMP>`X v = m ();'</SAMP>, whose result is of class
|
|
<CODE>X</CODE>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>X
|
|
m ()
|
|
{
|
|
X b;
|
|
b.a = 23;
|
|
return b;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX327"></A>
|
|
Although <CODE>m</CODE> appears to have no arguments, in fact it has one implicit
|
|
argument: the address of the return value. At invocation, the address
|
|
of enough space to hold <CODE>v</CODE> is sent in as the implicit argument.
|
|
Then <CODE>b</CODE> is constructed and its <CODE>a</CODE> field is set to the value
|
|
23. Finally, a copy constructor (a constructor of the form <SAMP>`X(X&)'</SAMP>)
|
|
is applied to <CODE>b</CODE>, with the (implicit) return value location as the
|
|
target, so that <CODE>v</CODE> is now bound to the return value.
|
|
</P><P>
|
|
|
|
But this is wasteful. The local <CODE>b</CODE> is declared just to hold
|
|
something that will be copied right out. While a compiler that
|
|
combined an "elision" algorithm with interprocedural data flow
|
|
analysis could conceivably eliminate all of this, it is much more
|
|
practical to allow you to assist the compiler in generating
|
|
efficient code by manipulating the return value explicitly,
|
|
thus avoiding the local variable and copy constructor altogether.
|
|
</P><P>
|
|
|
|
Using the extended GNU C++ function-definition syntax, you can avoid the
|
|
temporary allocation and copying by naming <CODE>r</CODE> as your return value
|
|
at the outset, and assigning to its <CODE>a</CODE> field directly:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>X
|
|
m () return r;
|
|
{
|
|
r.a = 23;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The declaration of <CODE>r</CODE> is a standard, proper declaration, whose effects
|
|
are executed <STRONG>before</STRONG> any of the body of <CODE>m</CODE>.
|
|
</P><P>
|
|
|
|
Functions of this type impose no additional restrictions; in particular,
|
|
you can execute <CODE>return</CODE> statements, or return implicitly by
|
|
reaching the end of the function body ("falling off the edge").
|
|
Cases like
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>X
|
|
m () return r (23);
|
|
{
|
|
return;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
(or even <SAMP>`X m () return r (23); { }'</SAMP>) are unambiguous, since
|
|
the return value <CODE>r</CODE> has been initialized in either case. The
|
|
following code may be hard to read, but also works predictably:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>X
|
|
m () return r;
|
|
{
|
|
X b;
|
|
return b;
|
|
}
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The return value slot denoted by <CODE>r</CODE> is initialized at the outset,
|
|
but the statement <SAMP>`return b;'</SAMP> overrides this value. The compiler
|
|
deals with this by destroying <CODE>r</CODE> (calling the destructor if there
|
|
is one, or doing nothing if there is not), and then reinitializing
|
|
<CODE>r</CODE> with <CODE>b</CODE>.
|
|
</P><P>
|
|
|
|
This extension is provided primarily to help people who use overloaded
|
|
operators, where there is a great need to control not just the
|
|
arguments, but the return values of functions. For classes where the
|
|
copy constructor incurs a heavy performance penalty (especially in the
|
|
common case where there is a quick default constructor), this is a major
|
|
savings. The disadvantage of this extension is that you do not control
|
|
when the default constructor for the return value is called: it is
|
|
always called at the beginning.
|
|
</P><P>
|
|
|
|
<A NAME="Min and Max"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC107"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC106" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC106"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC108" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC108"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC108" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC108"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.2 Minimum and Maximum Operators in C++ </H2>
|
|
<!--docid::SEC107::-->
|
|
<P>
|
|
|
|
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),
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE><VAR>a</VAR> <? <VAR>b</VAR></CODE>
|
|
<DD><A NAME="IDX328"></A>
|
|
<A NAME="IDX329"></A>
|
|
is the <EM>minimum</EM>, returning the smaller of the numeric values
|
|
<VAR>a</VAR> and <VAR>b</VAR>;
|
|
<P>
|
|
|
|
<DT><CODE><VAR>a</VAR> >? <VAR>b</VAR></CODE>
|
|
<DD><A NAME="IDX330"></A>
|
|
<A NAME="IDX331"></A>
|
|
is the <EM>maximum</EM>, returning the larger of the numeric values <VAR>a</VAR>
|
|
and <VAR>b</VAR>.
|
|
</DL>
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You might then use <SAMP>`int min = MIN (i, j);'</SAMP> to set <VAR>min</VAR> to
|
|
the minimum value of variables <VAR>i</VAR> and <VAR>j</VAR>.
|
|
</P><P>
|
|
|
|
However, side effects in <CODE>X</CODE> or <CODE>Y</CODE> may cause unintended
|
|
behavior. For example, <CODE>MIN (i++, j++)</CODE> will fail, incrementing
|
|
the smaller counter twice. A GNU C extension allows you to write safe
|
|
macros that avoid this kind of problem (see section <A HREF="gcc_4.html#SEC67" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC67">Naming an Expression's Type</A>). However, writing <CODE>MIN</CODE> and <CODE>MAX</CODE> as
|
|
macros also forces you to use function-call notation for a
|
|
fundamental arithmetic operation. Using GNU C++ extensions, you can
|
|
write <SAMP>`int min = i <? j;'</SAMP> instead.
|
|
</P><P>
|
|
|
|
Since <CODE><?</CODE> and <CODE>>?</CODE> are built into the compiler, they properly
|
|
handle expressions with side-effects; <SAMP>`int min = i++ <? j++;'</SAMP>
|
|
works correctly.
|
|
</P><P>
|
|
|
|
<A NAME="Destructors and Goto"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC108"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC107" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC107"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC109" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC109"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC109" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC109"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.3 <CODE>goto</CODE> and Destructors in GNU C++ </H2>
|
|
<!--docid::SEC108::-->
|
|
<P>
|
|
|
|
<A NAME="IDX332"></A>
|
|
<A NAME="IDX333"></A>
|
|
In C++ programs, you can safely use the <CODE>goto</CODE> statement. When you
|
|
use it to exit a block which contains aggregates requiring destructors,
|
|
the destructors will run before the <CODE>goto</CODE> transfers control.
|
|
</P><P>
|
|
|
|
<A NAME="IDX334"></A>
|
|
The compiler still forbids using <CODE>goto</CODE> to <EM>enter</EM> a scope
|
|
that requires constructors.
|
|
</P><P>
|
|
|
|
<A NAME="C++ Interface"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC109"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC108" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC108"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC110" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC110"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC110" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC110"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.4 Declarations and Definitions in One Header </H2>
|
|
<!--docid::SEC109::-->
|
|
<P>
|
|
|
|
<A NAME="IDX335"></A>
|
|
<A NAME="IDX336"></A>
|
|
C++ object definitions can be quite complex. In principle, your source
|
|
code will need two kinds of things for each object that you use across
|
|
more than one source file. First, you need an <EM>interface</EM>
|
|
specification, describing its structure with type declarations and
|
|
function prototypes. Second, you need the <EM>implementation</EM> itself.
|
|
It can be tedious to maintain a separate interface description in a
|
|
header file, in parallel to the actual implementation. It is also
|
|
dangerous, since separate interface and implementation definitions may
|
|
not remain parallel.
|
|
</P><P>
|
|
|
|
<A NAME="IDX337"></A>
|
|
With GNU C++, you can use a single header file for both purposes.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE>
|
|
<EM>Warning:</EM> The mechanism to specify this is in transition. For the
|
|
nonce, you must use one of two <CODE>#pragma</CODE> commands; in a future
|
|
release of GNU C++, an alternative mechanism will make these
|
|
<CODE>#pragma</CODE> commands unnecessary.
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
|
|
The header file contains the full definitions, but is marked with
|
|
<SAMP>`#pragma interface'</SAMP> in the source code. This allows the compiler
|
|
to use the header file only as an interface specification when ordinary
|
|
source files incorporate it with <CODE>#include</CODE>. In the single source
|
|
file where the full implementation belongs, you can use either a naming
|
|
convention or <SAMP>`#pragma implementation'</SAMP> to indicate this alternate
|
|
use of the header file.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>#pragma interface</CODE>
|
|
<DD><DT><CODE>#pragma interface "<VAR>subdir</VAR>/<VAR>objects</VAR>.h"</CODE>
|
|
<DD><A NAME="IDX338"></A>
|
|
Use this directive in <EM>header files</EM> 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 <SAMP>`#pragma interface'</SAMP> is included in a
|
|
compilation, this auxiliary information will not be generated (unless
|
|
the main input source file itself uses <SAMP>`#pragma implementation'</SAMP>).
|
|
Instead, the object files will contain references to be resolved at link
|
|
time.
|
|
<P>
|
|
|
|
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 <SAMP>`#pragma
|
|
implementation'</SAMP>.
|
|
</P><P>
|
|
|
|
<DT><CODE>#pragma implementation</CODE>
|
|
<DD><DT><CODE>#pragma implementation "<VAR>objects</VAR>.h"</CODE>
|
|
<DD><A NAME="IDX339"></A>
|
|
Use this pragma in a <EM>main input file</EM>, when you want full output from
|
|
included header files to be generated (and made globally visible). The
|
|
included header file, in turn, should use <SAMP>`#pragma interface'</SAMP>.
|
|
Backup copies of inline member functions, debugging information, and the
|
|
internal tables used to implement virtual functions are all generated in
|
|
implementation files.
|
|
<P>
|
|
|
|
<A NAME="IDX340"></A>
|
|
<A NAME="IDX341"></A>
|
|
<A NAME="IDX342"></A>
|
|
If you use <SAMP>`#pragma implementation'</SAMP> with no argument, it applies to
|
|
an include file with the same basename<A NAME="DOCF2" HREF="gcc_fot.html#FOOT2" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_fot.html#FOOT2">(2)</A> as your source
|
|
file. For example, in <TT>`allclass.cc'</TT>, giving just
|
|
<SAMP>`#pragma implementation'</SAMP>
|
|
by itself is equivalent to <SAMP>`#pragma implementation "allclass.h"'</SAMP>.
|
|
</P><P>
|
|
|
|
In versions of GNU C++ prior to 2.6.0 <TT>`allclass.h'</TT> was treated as
|
|
an implementation file whenever you would include it from
|
|
<TT>`allclass.cc'</TT> even if you never specified <SAMP>`#pragma
|
|
implementation'</SAMP>. This was deemed to be more trouble than it was worth,
|
|
however, and disabled.
|
|
</P><P>
|
|
|
|
If you use an explicit <SAMP>`#pragma implementation'</SAMP>, it must appear in
|
|
your source file <EM>before</EM> you include the affected header files.
|
|
</P><P>
|
|
|
|
Use the string argument if you want a single implementation file to
|
|
include code from multiple header files. (You must also use
|
|
<SAMP>`#include'</SAMP> to include the header file; <SAMP>`#pragma
|
|
implementation'</SAMP> only specifies how to use the file--it doesn't actually
|
|
include it.)
|
|
</P><P>
|
|
|
|
There is no way to split up the contents of a single header file into
|
|
multiple implementation files.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="IDX343"></A>
|
|
<A NAME="IDX344"></A>
|
|
<A NAME="IDX345"></A>
|
|
<SAMP>`#pragma implementation'</SAMP> and <SAMP>`#pragma interface'</SAMP> also have an
|
|
effect on function inlining.
|
|
</P><P>
|
|
|
|
If you define a class in a header file marked with <SAMP>`#pragma
|
|
interface'</SAMP>, the effect on a function defined in that class is similar to
|
|
an explicit <CODE>extern</CODE> 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.
|
|
</P><P>
|
|
|
|
Conversely, when you include the same header file in a main source file
|
|
that declares it as <SAMP>`#pragma implementation'</SAMP>, 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 <SAMP>`-fno-implement-inlines'</SAMP>.
|
|
If any calls were not inlined, you will get linker errors.
|
|
</P><P>
|
|
|
|
<A NAME="Template Instantiation"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC110"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC109" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC109"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC111" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC111"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC111" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC111"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.5 Where's the Template? </H2>
|
|
<!--docid::SEC110::-->
|
|
<P>
|
|
|
|
<A NAME="IDX346"></A>
|
|
</P><P>
|
|
|
|
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 I will refer to as the Borland model and the Cfront model.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT>Borland model
|
|
<DD>Borland C++ solved the template instantiation problem by adding the code
|
|
equivalent of common blocks to their linker; the compiler emits template
|
|
instances in each translation unit that uses them, and the linker
|
|
collapses them together. The advantage of this model is that the linker
|
|
only has to consider the object files themselves; there is no external
|
|
complexity to worry about. This disadvantage is that compilation time
|
|
is increased because the template code is being compiled repeatedly.
|
|
Code written for this model tends to include definitions of all
|
|
templates in the header file, since they must be seen to be
|
|
instantiated.
|
|
<P>
|
|
|
|
<DT>Cfront model
|
|
<DD>The AT&T C++ translator, Cfront, solved the template instantiation
|
|
problem by creating the notion of a template repository, an
|
|
automatically maintained place where template instances are stored. A
|
|
more modern version of the repository works as follows: As individual
|
|
object files are built, the compiler places any template definitions and
|
|
instantiations encountered in the repository. At link time, the link
|
|
wrapper adds in the objects in the repository and compiles any needed
|
|
instances that were not previously emitted. The advantages of this
|
|
model are more optimal compilation speed and the ability to use the
|
|
system linker; to implement the Borland model a compiler vendor also
|
|
needs to replace the linker. The disadvantages are vastly increased
|
|
complexity, and thus potential for error; for some code this can be
|
|
just as transparent, but in practice it can been very difficult to build
|
|
multiple programs in one directory and one program in multiple
|
|
directories. Code written for this model tends to separate definitions
|
|
of non-inline member templates into a separate file, which should be
|
|
compiled separately.
|
|
</DL>
|
|
<P>
|
|
|
|
When used with GNU ld version 2.8 or later on an ELF system such as
|
|
Linux/GNU or Solaris 2, or on Microsoft Windows, g++ supports the
|
|
Borland model. On other systems, g++ implements neither automatic
|
|
model.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
In the mean time, you have the following options for dealing with
|
|
template instantiations:
|
|
</P><P>
|
|
|
|
<OL>
|
|
<LI>
|
|
Compile your template-using code with <SAMP>`-frepo'</SAMP>. The compiler will
|
|
generate files with the extension <SAMP>`.rpo'</SAMP> listing all of the
|
|
template instantiations used in the corresponding object files which
|
|
could be instantiated there; the link wrapper, <SAMP>`collect2'</SAMP>, will
|
|
then update the <SAMP>`.rpo'</SAMP> files to tell the compiler where to place
|
|
those instantiations and rebuild any affected object files. The
|
|
link-time overhead is negligible after the first pass, as the compiler
|
|
will continue to place the instantiations in the same files.
|
|
<P>
|
|
|
|
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
|
|
<CODE>#include <tmethods.cc></CODE> to the end of each template header.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Compile your code with <SAMP>`-fno-implicit-templates'</SAMP> to disable the
|
|
implicit generation of template instances, and explicitly instantiate
|
|
all the ones you use. This approach requires more knowledge of exactly
|
|
which instances you need than do the others, but it's less
|
|
mysterious and allows greater control. You can scatter the explicit
|
|
instantiations throughout your program, perhaps putting them in the
|
|
translation units where the instances are used or the translation units
|
|
that define the templates themselves; you can put all of the explicit
|
|
instantiations you need into one big file; or you can create small files
|
|
like
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>#include "Foo.h"
|
|
#include "Foo.cc"
|
|
|
|
template class Foo<int>;
|
|
template ostream& operator <<
|
|
(ostream&, const Foo<int>&);
|
|
</pre></td></tr></table></P><P>
|
|
|
|
for each of the instances you need, and create a template instantiation
|
|
library from those.
|
|
</P><P>
|
|
|
|
If you are using Cfront-model code, you can probably get away with not
|
|
using <SAMP>`-fno-implicit-templates'</SAMP> when compiling files that don't
|
|
<SAMP>`#include'</SAMP> the member template definitions.
|
|
</P><P>
|
|
|
|
If you use one big file to do the instantiations, you may want to
|
|
compile it without <SAMP>`-fno-implicit-templates'</SAMP> 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.
|
|
</P><P>
|
|
|
|
g++ has extended the template instantiation syntax outlined in the
|
|
Working Paper to allow forward declaration of explicit instantiations
|
|
and instantiation of the compiler support data for a template class
|
|
(i.e. the vtable) without instantiating any of its members:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>extern template int max (int, int);
|
|
inline template class Foo<int>;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<LI>
|
|
Do nothing. Pretend g++ does implement automatic instantiation
|
|
management. Code written for the Borland model will work fine, but
|
|
each translation unit will contain instances of each of the templates it
|
|
uses. In a large program, this can lead to an unacceptable amount of code
|
|
duplication.
|
|
<P>
|
|
|
|
<LI>
|
|
Add <SAMP>`#pragma interface'</SAMP> to all files containing template
|
|
definitions. For each of these files, add <SAMP>`#pragma implementation
|
|
"<VAR>filename</VAR>"'</SAMP> to the top of some <SAMP>`.C'</SAMP> file which
|
|
<SAMP>`#include'</SAMP>s it. Then compile everything with
|
|
<SAMP>`-fexternal-templates'</SAMP>. The templates will then only be expanded
|
|
in the translation unit which implements them (i.e. has a <SAMP>`#pragma
|
|
implementation'</SAMP> line for the file where they live); all other files will
|
|
use external references. If you're lucky, everything should work
|
|
properly. If you get undefined symbol errors, you need to make sure
|
|
that each template instance which is used in the program is used in the
|
|
file which implements that template. If you don't have any use for a
|
|
particular instance in that file, you can just instantiate it
|
|
explicitly, using the syntax from the latest C++ working paper:
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>template class A<int>;
|
|
template ostream& operator << (ostream&, const A<int>&);
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This strategy will work with code written for either model. If you are
|
|
using code written for the Cfront model, the file containing a class
|
|
template and the file containing its member templates should be
|
|
implemented in the same translation unit.
|
|
</P><P>
|
|
|
|
A slight variation on this approach is to instead use the flag
|
|
<SAMP>`-falt-external-templates'</SAMP>; this flag causes template
|
|
instances to be emitted in the translation unit that implements the
|
|
header where they are first instantiated, rather than the one which
|
|
implements the file where the templates are defined. This header must
|
|
be the same in all translation units, or things are likely to break.
|
|
</P><P>
|
|
|
|
See section <A HREF="gcc_5.html#SEC109" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC109">Declarations and Definitions in One Header</A>, for
|
|
more discussion of these pragmas.
|
|
</OL>
|
|
<P>
|
|
|
|
<A NAME="Bound member functions"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC111"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC110" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC110"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC112" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC112" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.6 Extracting the function pointer from a bound pointer to member function </H2>
|
|
<!--docid::SEC111::-->
|
|
<P>
|
|
|
|
<A NAME="IDX347"></A>
|
|
<A NAME="IDX348"></A>
|
|
<A NAME="IDX349"></A>
|
|
</P><P>
|
|
|
|
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 <SAMP>`this'</SAMP> 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.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
The syntax for this extension is
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>extern A a;
|
|
extern int (A::*fp)();
|
|
typedef int (*fptr)(A *);
|
|
|
|
fptr p = (fptr)(a.*fp);
|
|
</pre></td></tr></table></P><P>
|
|
|
|
You must specify <SAMP>`-Wno-pmf-conversions'</SAMP> to use this extension.
|
|
</P><P>
|
|
|
|
<A NAME="C++ Signatures"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC112"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC111" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC111"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.7 Type Abstraction using Signatures </H2>
|
|
<!--docid::SEC112::-->
|
|
<P>
|
|
|
|
<A NAME="IDX350"></A>
|
|
<A NAME="IDX351"></A>
|
|
<A NAME="IDX352"></A>
|
|
<A NAME="IDX353"></A>
|
|
<A NAME="IDX354"></A>
|
|
<A NAME="IDX355"></A>
|
|
<A NAME="IDX356"></A>
|
|
</P><P>
|
|
|
|
In GNU C++, you can use the keyword <CODE>signature</CODE> 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'</SAMP> command-line option. (With this option, the
|
|
compiler reserves a second keyword <CODE>sigof</CODE> as well, for a future
|
|
extension.)
|
|
</P><P>
|
|
|
|
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++</CITE>
|
|
by 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
|
|
<EM>Software--Practice & Experience</EM>, <B>25</B>(8), pp. 863--889,
|
|
August 1995). You can get the tech report by anonymous FTP from
|
|
<CODE>ftp.cs.purdue.edu</CODE> in <TT>`pub/gb/Signature-design.ps.gz'</TT>.
|
|
</P><P>
|
|
|
|
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</CODE> with member functions <SAMP>`int foo ()'</SAMP> and <SAMP>`int bar (int)'</SAMP>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>signature S
|
|
{
|
|
int foo ();
|
|
int bar (int);
|
|
};
|
|
</pre></td></tr></table></P><P>
|
|
|
|
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
|
|
<EM>signature pointer</EM>. Such a class <EM>implements</EM> the signature
|
|
type.
|
|
</P><P>
|
|
|
|
To use a class as an implementation of <CODE>S</CODE>, you must ensure that
|
|
the class has public member functions <SAMP>`int foo ()'</SAMP> and <SAMP>`int
|
|
bar (int)'</SAMP>. 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.
|
|
</P><P>
|
|
|
|
For example, suppose that <CODE>C</CODE> is a class that meets the
|
|
requirements of signature <CODE>S</CODE> (<CODE>C</CODE> <EM>conforms to</EM>
|
|
<CODE>S</CODE>). Then
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>C obj;
|
|
S * p = &obj;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
defines a signature pointer <CODE>p</CODE> and initializes it to point to an
|
|
object of type <CODE>C</CODE>.
|
|
The member function call <SAMP>`int i = p->foo ();'</SAMP>
|
|
executes <SAMP>`obj.foo ()'</SAMP>.
|
|
</P><P>
|
|
|
|
<A NAME="IDX357"></A>
|
|
Abstract virtual classes provide somewhat similar facilities in standard
|
|
C++. There are two main advantages to using signatures instead:
|
|
</P><P>
|
|
|
|
<OL>
|
|
<LI>
|
|
Subtyping becomes independent from inheritance. A class or signature
|
|
type <CODE>T</CODE> is a subtype of a signature type <CODE>S</CODE> independent of
|
|
any inheritance hierarchy as long as all the member functions declared
|
|
in <CODE>S</CODE> are also found in <CODE>T</CODE>. 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.
|
|
<P>
|
|
|
|
<LI>
|
|
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.
|
|
</OL>
|
|
<P>
|
|
|
|
<A NAME="IDX358"></A>
|
|
<A NAME="IDX359"></A>
|
|
There is one more detail about signatures. A signature declaration can
|
|
contain member function <EM>definitions</EM> as well as member function
|
|
declarations. A signature member function with a full definition is
|
|
called a <EM>default implementation</EM>; classes need not contain that
|
|
particular interface in order to conform. For example, a
|
|
class <CODE>C</CODE> can conform to the signature
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>signature T
|
|
{
|
|
int f (int);
|
|
int f0 () { return f (0); };
|
|
};
|
|
</pre></td></tr></table></P><P>
|
|
|
|
whether or not <CODE>C</CODE> implements the member function <SAMP>`int f0 ()'</SAMP>.
|
|
If you define <CODE>C::f0</CODE>, that definition takes precedence;
|
|
otherwise, the default implementation <CODE>S::f0</CODE> applies.
|
|
</P><P>
|
|
|
|
<A NAME="Gcov"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_5.html#SEC105" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC105"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_6.html#SEC113" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_6.html#SEC113"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
This document was generated
|
|
by <I>GCC Administrator</I> on <I>March, 17 2001</I>
|
|
using <A HREF="tppmsgs/msgs0.htm#1" tppabs="http://www.mathematik.uni-kl.de/~obachman/Texi2html"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|