home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 8 / FreshFishVol8-CD2.bin / bbs / gnu / gcc-2.6.3-bin.lha / GNU / info / gcc.info-9 (.txt) < prev   
GNU Info File  |  1994-12-23  |  50KB  |  851 lines
  1. This is Info file gcc.info, produced by Makeinfo-1.55 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, 1994 Free Software Foundation,
  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," "Funding for
  13. Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
  14. included exactly as in the original, and provided that the entire
  15. resulting derived work is distributed under the terms of a permission
  16. notice identical to this one.
  17.    Permission is granted to copy and distribute translations of this
  18. manual into another language, under the above conditions for modified
  19. versions, except that the sections entitled "GNU General Public
  20. License," "Funding for Free Software," and "Protect Your Freedom--Fight
  21. `Look And Feel'", and this permission notice, may be included in
  22. translations approved by the Free Software Foundation instead of in the
  23. original English.
  24. File: gcc.info,  Node: Min and Max,  Next: Destructors and Goto,  Prev: Naming Results,  Up: C++ Extensions
  25. Minimum and Maximum Operators in C++
  26. ====================================
  27.    It is very convenient to have operators which return the "minimum"
  28. or the "maximum" of two arguments.  In GNU C++ (but not in GNU C),
  29. `A <? B'
  30.      is the "minimum", returning the smaller of the numeric values A
  31.      and B;
  32. `A >? B'
  33.      is the "maximum", returning the larger of the numeric values A and
  34.      B.
  35.    These operations are not primitive in ordinary C++, since you can
  36. use a macro to return the minimum of two things in C++, as in the
  37. following example.
  38.      #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))
  39. You might then use `int min = MIN (i, j);' to set MIN to the minimum
  40. value of variables I and J.
  41.    However, side effects in `X' or `Y' may cause unintended behavior.
  42. For example, `MIN (i++, j++)' will fail, incrementing the smaller
  43. counter twice.  A GNU C extension allows you to write safe macros that
  44. avoid this kind of problem (*note Naming an Expression's Type: Naming
  45. Types.).  However, writing `MIN' and `MAX' as macros also forces you to
  46. use function-call notation notation for a fundamental arithmetic
  47. operation.  Using GNU C++ extensions, you can write `int min = i <? j;'
  48. instead.
  49.    Since `<?' and `>?' are built into the compiler, they properly
  50. handle expressions with side-effects;  `int min = i++ <? j++;' works
  51. correctly.
  52. File: gcc.info,  Node: Destructors and Goto,  Next: C++ Interface,  Prev: Min and Max,  Up: C++ Extensions
  53. `goto' and Destructors in GNU C++
  54. =================================
  55.    In C++ programs, you can safely use the `goto' statement.  When you
  56. use it to exit a block which contains aggregates requiring destructors,
  57. the destructors will run before the `goto' transfers control.  (In ANSI
  58. C++, `goto' is restricted to targets within the current block.)
  59.    The compiler still forbids using `goto' to *enter* a scope that
  60. requires constructors.
  61. File: gcc.info,  Node: C++ Interface,  Next: Template Instantiation,  Prev: Destructors and Goto,  Up: C++ Extensions
  62. Declarations and Definitions in One Header
  63. ==========================================
  64.    C++ object definitions can be quite complex.  In principle, your
  65. source code will need two kinds of things for each object that you use
  66. across more than one source file.  First, you need an "interface"
  67. specification, describing its structure with type declarations and
  68. function prototypes.  Second, you need the "implementation" itself.  It
  69. can be tedious to maintain a separate interface description in a header
  70. file, in parallel to the actual implementation.  It is also dangerous,
  71. since separate interface and implementation definitions may not remain
  72. parallel.
  73.    With GNU C++, you can use a single header file for both purposes.
  74.      *Warning:* The mechanism to specify this is in transition.  For the
  75.      nonce, you must use one of two `#pragma' commands; in a future
  76.      release of GNU C++, an alternative mechanism will make these
  77.      `#pragma' commands unnecessary.
  78.    The header file contains the full definitions, but is marked with
  79. `#pragma interface' in the source code.  This allows the compiler to
  80. use the header file only as an interface specification when ordinary
  81. source files incorporate it with `#include'.  In the single source file
  82. where the full implementation belongs, you can use either a naming
  83. convention or `#pragma implementation' to indicate this alternate use
  84. of the header file.
  85. `#pragma interface'
  86. `#pragma interface "SUBDIR/OBJECTS.h"'
  87.      Use this directive in *header files* that define object classes,
  88.      to save space in most of the object files that use those classes.
  89.      Normally, local copies of certain information (backup copies of
  90.      inline member functions, debugging information, and the internal
  91.      tables that implement virtual functions) must be kept in each
  92.      object file that includes class definitions.  You can use this
  93.      pragma to avoid such duplication.  When a header file containing
  94.      `#pragma interface' is included in a compilation, this auxiliary
  95.      information will not be generated (unless the main input source
  96.      file itself uses `#pragma implementation').  Instead, the object
  97.      files will contain references to be resolved at link time.
  98.      The second form of this directive is useful for the case where you
  99.      have multiple headers with the same name in different directories.
  100.      If you use this form, you must specify the same string to `#pragma
  101.      implementation'.
  102. `#pragma implementation'
  103. `#pragma implementation "OBJECTS.h"'
  104.      Use this pragma in a *main input file*, when you want full output
  105.      from included header files to be generated (and made globally
  106.      visible).  The included header file, in turn, should use `#pragma
  107.      interface'.  Backup copies of inline member functions, debugging
  108.      information, and the internal tables used to implement virtual
  109.      functions are all generated in implementation files.
  110.      If you use `#pragma implementation' with no argument, it applies to
  111.      an include file with the same basename(1) as your source file.
  112.      For example, in `allclass.cc', `#pragma implementation' by itself
  113.      is equivalent to `#pragma implementation "allclass.h"'.
  114.      In versions of GNU C++ prior to 2.6.0 `allclass.h' was treated as
  115.      an implementation file whenever you would include it from
  116.      `allclass.cc' even if you never specified `#pragma
  117.      implementation'.  This was deemed to be more trouble than it was
  118.      worth, however, and disabled.
  119.      If you use an explicit `#pragma implementation', it must appear in
  120.      your source file *before* you include the affected header files.
  121.      Use the string argument if you want a single implementation file to
  122.      include code from multiple header files.  (You must also use
  123.      `#include' to include the header file; `#pragma implementation'
  124.      only specifies how to use the file--it doesn't actually include
  125.      it.)
  126.      There is no way to split up the contents of a single header file
  127.      into multiple implementation files.
  128.    `#pragma implementation' and `#pragma interface' also have an effect
  129. on function inlining.
  130.    If you define a class in a header file marked with `#pragma
  131. interface', the effect on a function defined in that class is similar to
  132. an explicit `extern' declaration--the compiler emits no code at all to
  133. define an independent version of the function.  Its definition is used
  134. only for inlining with its callers.
  135.    Conversely, when you include the same header file in a main source
  136. file that declares it as `#pragma implementation', the compiler emits
  137. code for the function itself; this defines a version of the function
  138. that can be found via pointers (or by callers compiled without
  139. inlining).  If all c