home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 7
/
FreshFishVol7.bin
/
bbs
/
gnu
/
gcc-2.5.8-bin.lha
/
GNU
/
info
/
gcc.info-9
(
.txt
)
< prev
Wrap
GNU Info File
|
1994-09-02
|
44KB
|
756 lines
This is Info file gcc.info, produced by Makeinfo-1.54 from the input
file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 675 Massachusetts Avenue
Cambridge, MA 02139 USA
Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License" and "Protect
Your Freedom--Fight `Look And Feel'" are included exactly as in the
original, and provided that the entire resulting derived work is
distributed under the terms of a permission notice identical to this
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License" and "Protect Your Freedom--Fight `Look And Feel'", and this
permission notice, may be included in translations approved by the Free
Software Foundation instead of in the original English.
File: gcc.info, Node: C++ Interface, Next: C++ Signatures, Prev: Destructors and Goto, Up: C++ Extensions
Declarations and Definitions in One Header
==========================================
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 "interface"
specification, describing its structure with type declarations and
function prototypes. Second, you need the "implementation" 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.
With GNU C++, you can use a single header file for both purposes.
*Warning:* The mechanism to specify this is in transition. For the
nonce, you must use one of two `#pragma' commands; in a future
release of GNU C++, an alternative mechanism will make these
`#pragma' commands unnecessary.
The header file contains the full definitions, but is marked with
`#pragma interface' 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 `#include'. In the single source file
where the full implementation belongs, you can use either a naming
convention or `#pragma implementation' to indicate this alternate use
of the header file.
`#pragma interface'
Use this directive in *header files* 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
`#pragma interface' is included in a compilation, this auxiliary
information will not be generated (unless the main input source
file itself uses `#pragma implementation'). Instead, the object
files will contain references to be resolved at link time.
`#pragma implementation'
`#pragma implementation "OBJECTS.h"'
Use this pragma in a *main input file*, when you want full output
from included header files to be generated (and made globally
visible). The included header file, in turn, should use `#pragma
interface'. Backup copies of inline member functions, debugging
information, and the internal tables used to implement virtual
functions are all generated in implementation files.
`#pragma implementation' is *implied* whenever the basename(1) of
your source file matches the basename of a header file it
includes. There is no way to turn this off (other than using a
different name for one of the two files). In the same vein, if
you use `#pragma implementation' with no argument, it applies to an
include file with the same basename as your source file. For
example, in `allclass.cc', `#pragma implementation' by itself is
equivalent to `#pragma implementation "allclass.h"'; but even if
you do not say `#pragma implementation' at all, `allclass.h' is
treated as an implementation file whenever you include it from
`allclass.cc'.
If you use an explicit `#pragma implementation', it must appear in
your source file *before* you include the affected header files.
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 a 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).
---------- Footnotes ----------
(1) A file's "basename" is the name stripped of all leading path
information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
File: gcc.info, Node: C++ Signatures, Prev: C++ Interface, Up: C++ Extensions
Type Abstraction using Signatures
=================================
In GNU C++, you can use the keyword `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 `-fhandle-signatures'
command-line option. (With this option, the compiler reserves a second
keyword `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 `Signatures:
A C++ Extension for Type Abstraction and Subtype Polymorphism' by
Gerald Baumgartner and Vincent F. Russo (Tech report CSD-TR-93-059,
Dept. of Computer Sciences, Purdue University, September 1993, to
appear in *Software Practice & Experience*). You can get the tech
report by anonymous FTP from `ftp.cs.purdue.edu' in
`pub/reports/TR93-059.PS.Z'.
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 `S' with member
functions `int foo ()' and `int bar (int)':
signature S
{
int foo ();
int bar (int);
};
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
"signature pointer". Such a class "implements" the signature type.
To use a class as an implementation of `S', you must ensure that the
class has public member functions