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   
GNU Info File  |  1994-09-02  |  44KB  |  756 lines
  1. This is Info file gcc.info, produced by Makeinfo-1.54 from the input
  2. file gcc.texi.
  3.    This file documents the use and the internals of the GNU compiler.
  4.    Published by the Free Software Foundation 675 Massachusetts Avenue
  5. Cambridge, MA 02139 USA
  6.    Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
  7.    Permission is granted to make and distribute verbatim copies of this
  8. manual provided the copyright notice and this permission notice are
  9. preserved on all copies.
  10.    Permission is granted to copy and distribute modified versions of
  11. this manual under the conditions for verbatim copying, provided also
  12. that the sections entitled "GNU General Public License" and "Protect
  13. Your Freedom--Fight `Look And Feel'" are included exactly as in the
  14. original, and provided that the entire resulting derived work is
  15. distributed under the terms of a permission notice identical to this
  16.    Permission is granted to copy and distribute translations of this
  17. manual into another language, under the above conditions for modified
  18. versions, except that the sections entitled "GNU General Public
  19. License" and "Protect Your Freedom--Fight `Look And Feel'", and this
  20. permission notice, may be included in translations approved by the Free
  21. Software Foundation instead of in the original English.
  22. File: gcc.info,  Node: C++ Interface,  Next: C++ Signatures,  Prev: Destructors and Goto,  Up: C++ Extensions
  23. Declarations and Definitions in One Header
  24. ==========================================
  25.    C++ object definitions can be quite complex.  In principle, your
  26. source code will need two kinds of things for each object that you use
  27. across more than one source file.  First, you need an "interface"
  28. specification, describing its structure with type declarations and
  29. function prototypes.  Second, you need the "implementation" itself.  It
  30. can be tedious to maintain a separate interface description in a header
  31. file, in parallel to the actual implementation.  It is also dangerous,
  32. since separate interface and implementation definitions may not remain
  33. parallel.
  34.    With GNU C++, you can use a single header file for both purposes.
  35.      *Warning:* The mechanism to specify this is in transition.  For the
  36.      nonce, you must use one of two `#pragma' commands; in a future
  37.      release of GNU C++, an alternative mechanism will make these
  38.      `#pragma' commands unnecessary.
  39.    The header file contains the full definitions, but is marked with
  40. `#pragma interface' in the source code.  This allows the compiler to
  41. use the header file only as an interface specification when ordinary
  42. source files incorporate it with `#include'.  In the single source file
  43. where the full implementation belongs, you can use either a naming
  44. convention or `#pragma implementation' to indicate this alternate use
  45. of the header file.
  46. `#pragma interface'
  47.      Use this directive in *header files* that define object classes,
  48.      to save space in most of the object files that use those classes.
  49.      Normally, local copies of certain information (backup copies of
  50.      inline member functions, debugging information, and the internal
  51.      tables that implement virtual functions) must be kept in each
  52.      object file that includes class definitions.  You can use this
  53.      pragma to avoid such duplication.  When a header file containing
  54.      `#pragma interface' is included in a compilation, this auxiliary
  55.      information will not be generated (unless the main input source
  56.      file itself uses `#pragma implementation').  Instead, the object
  57.      files will contain references to be resolved at link time.
  58. `#pragma implementation'
  59. `#pragma implementation "OBJECTS.h"'
  60.      Use this pragma in a *main input file*, when you want full output
  61.      from included header files to be generated (and made globally
  62.      visible).  The included header file, in turn, should use `#pragma
  63.      interface'.  Backup copies of inline member functions, debugging
  64.      information, and the internal tables used to implement virtual
  65.      functions are all generated in implementation files.
  66.      `#pragma implementation' is *implied* whenever the basename(1) of
  67.      your source file matches the basename of a header file it
  68.      includes.  There is no way to turn this off (other than using a
  69.      different name for one of the two files).  In the same vein, if
  70.      you use `#pragma implementation' with no argument, it applies to an
  71.      include file with the same basename as your source file.  For
  72.      example, in `allclass.cc', `#pragma implementation' by itself is
  73.      equivalent to `#pragma implementation "allclass.h"'; but even if
  74.      you do not say `#pragma implementation' at all, `allclass.h' is
  75.      treated as an implementation file whenever you include it from
  76.      `allclass.cc'.
  77.      If you use an explicit `#pragma implementation', it must appear in
  78.      your source file *before* you include the affected header files.
  79.      Use the string argument if you want a single implementation file to
  80.      include code from multiple header files.  (You must also use
  81.      `#include' to include the header file; `#pragma implementation'
  82.      only specifies how to use the file--it doesn't actually include
  83.      it.)
  84.      There is no way to split up the contents of a single header file
  85.      into multiple implementation files.
  86.    `#pragma implementation' and `#pragma interface' also have an effect
  87. on function inlining.
  88.    If you define a class in a header file marked with `#pragma
  89. interface', the effect on a function defined in that class is similar to
  90. an explicit `extern' declaration--the compiler emits no code at all to
  91. define an independent version of the function.  Its definition is used
  92. only for inlining with its callers.
  93.    Conversely, when you include the same header file in a main source
  94. file that declares it as `#pragma implementation', the compiler emits
  95. code for the function itself; this defines a version of the function
  96. that can be found via pointers (or by callers compiled without
  97. inlining).
  98.    ---------- Footnotes ----------
  99.    (1)  A file's "basename" is the name stripped of all leading path
  100. information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
  101. File: gcc.info,  Node: C++ Signatures,  Prev: C++ Interface,  Up: C++ Extensions
  102. Type Abstraction using Signatures
  103. =================================
  104.    In GNU C++, you can use the keyword `signature' to define a
  105. completely abstract class interface as a datatype.  You can connect this
  106. abstraction with actual classes using signature pointers.  If you want
  107. to use signatures, run the GNU compiler with the `-fhandle-signatures'
  108. command-line option.  (With this option, the compiler reserves a second
  109. keyword `sigof' as well, for a future extension.)
  110.    Roughly, signatures are type abstractions or interfaces of classes.
  111. Some other languages have similar facilities.  C++ signatures are
  112. related to ML's signatures, Haskell's type classes, definition modules
  113. in Modula-2, interface modules in Modula-3, abstract types in Emerald,
  114. type modules in Trellis/Owl, categories in Scratchpad II, and types in
  115. POOL-I.  For a more detailed discussion of signatures, see `Signatures:
  116. A C++ Extension for Type Abstraction and Subtype Polymorphism' by
  117. Gerald Baumgartner and Vincent F. Russo (Tech report CSD-TR-93-059,
  118. Dept. of Computer Sciences, Purdue University, September 1993, to
  119. appear in *Software Practice & Experience*).  You can get the tech
  120. report by anonymous FTP from `ftp.cs.purdue.edu' in
  121. `pub/reports/TR93-059.PS.Z'.
  122.    Syntactically, a signature declaration is a collection of member
  123. function declarations and nested type declarations.  For example, this
  124. signature declaration defines a new abstract type `S' with member
  125. functions `int foo ()' and `int bar (int)':
  126.      signature S
  127.      {
  128.        int foo ();
  129.        int bar (int);
  130.      };
  131.    Since signature types do not include implementation definitions, you
  132. cannot write an instance of a signature directly.  Instead, you can
  133. define a pointer to any class that contains the required interfaces as a
  134. "signature pointer".  Such a class "implements" the signature type.
  135.    To use a class as an implementation of `S', you must ensure that the
  136. class has public member functions