home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 4 / FreshFish_May-June1994.bin / gnu / info / libg++.info-2 (.txt) < prev    next >
GNU Info File  |  1994-02-27  |  50KB  |  912 lines

  1. This is Info file libg++.info, produced by Makeinfo-1.55 from the input
  2. file ./libg++.texi.
  3. START-INFO-DIR-ENTRY
  4. * Libg++::                      The g++ class library.
  5. END-INFO-DIR-ENTRY
  6.    This file documents the features and implementation of The GNU C++
  7. library
  8.    Copyright (C) 1988, 1991, 1992 Free Software Foundation, Inc.
  9.    Permission is granted to make and distribute verbatim copies of this
  10. manual provided the copyright notice and this permission notice are
  11. preserved on all copies.
  12.    Permission is granted to copy and distribute modified versions of
  13. this manual under the conditions for verbatim copying, provided also
  14. that the section entitled "GNU Library General Public License" is
  15. included exactly as in the original, and provided that the entire
  16. resulting derived work is distributed under the terms of a permission
  17. notice identical to this one.
  18.    Permission is granted to copy and distribute translations of this
  19. manual into another language, under the above conditions for modified
  20. versions, except that the section entitled "GNU Library General Public
  21. License" and this permission notice may be included in translations
  22. approved by the Free Software Foundation instead of in the original
  23. English.
  24. File: libg++.info,  Node: Proto,  Next: Representations,  Prev: OK,  Up: Top
  25. Introduction to container class prototypes
  26. ******************************************
  27.    As a temporary mechanism enabling the support of generic classes,
  28. the GNU C++ Library distribution contains a directory (`g++-include')
  29. of files designed to serve as the basis for generating container
  30. classes of specified elements.  These files can be used to generate
  31. `.h' and `.cc' files in the current directory via a supplied shell
  32. script program that performs simple textual substitution to create
  33. specific classes.
  34.    While these classes are generated independently, and thus share no
  35. code, it is possible to create versions that do share code among
  36. subclasses. For example, using `typedef void* ent', and then generating
  37. a `entList' class, other derived classes could be created using the
  38. `void*' coercion method described in Stroustrup, pp204-210.
  39.    This very simple class-generation facility is useful enough to serve
  40. current purposes, but will be replaced with a more coherent mechanism
  41. for handling C++ generics in a way that minimally disrupts current
  42. usage.  Without knowing exactly when or how parametric classes might be
  43. added to the C++ language, provision of this simplest possible
  44. mechanism, textual substitution, appears to be the safest strategy,
  45. although it does require certain redundancies and awkward constructions.
  46.    Specific classes may be generated via the `genclass' shell script
  47. program. This program has arguments specifying the kinds of base
  48. types(s) to be used. Specifying base types requires two arguments. The
  49. first is the name of the base type, which may be any named type, like
  50. `int' or `String'. Only named types are supported; things like `int*'
  51. are not accepted. However, pointers like this may be used by supplying
  52. the appropriate typedefs (e.g., editing the resulting files to include
  53. `typedef int* intp;'). The type name must be followed by one of the
  54. words `val' or `ref', to indicate whether the base elements should be
  55. passed to functions by-value or by-reference.
  56.    You can specify basic container classes using `genclass base
  57. [val,ref] proto', where `proto' is the name of the class being
  58. generated.  Container classes like dictionaries and maps that require
  59. two types may be specified via `genclass -2 keytype [val, ref],
  60. basetype [val, ref] proto', where the key type is specified first and
  61. the contents type second.  The resulting classnames and filenames are
  62. generated by prepending the specified type names to the prototype names,
  63. and separating the filename parts with dots.  For example, `genclass
  64. int val List' generates class `intList' residing in files `int.List.h'
  65. and `int.List.cc'. `genclass -2 String ref int val VHMap' generates
  66. (the awkward, but unavoidable) class name `StringintVHMap'. Of course,
  67. programmers may use `typedef' or simple editing to create more
  68. appropriate names.  The existence of dot seperators in file names
  69. allows the use of GNU make to help automate configuration and
  70. recompilation. An example Makefile exploiting such capabilities may be
  71. found in the `libg++/proto-kit' directory.
  72.    The `genclass' utility operates via simple text substitution using
  73. `sed'. All occurrences of the pseudo-types `<T>' and `<C>' (if there
  74. are two types) are replaced with the indicated type, and occurrences of
  75. `<T&>' and `<C&>' are replaced by just the types, if `val' is
  76. specified, or types followed by "&" if `ref' is specified.
  77.    Programmers will frequently need to edit the `.h' file in order to
  78. insert additional `#include' directives or other modifications.  A
  79. simple utility, `prepend-header' to prepend other `.h' files to
  80. generated files is provided in the distribution.
  81.    One dubious virtue of the prototyping mechanism is that, because
  82. sources files, not archived library classes, are generated, it is
  83. relatively simple for programmers to modify container classes in the
  84. common case where slight variations of standard container classes are
  85. required.
  86.    It is often a good idea for programmers to archive (via `ar')
  87. generated classes into `.a' files so that only those class functions
  88. actually used in a given application will be loaded.  The test
  89. subdirectory of the distribution shows an example of this.
  90.    Because of `#pragma interface' directives, the `.cc' files should be
  91. compiled with `-O' or `-DUSE_LIBGXX_INLINES' enabled.
  92.    Many container classes require specifications over and above the base
  93. class type. For example, classes that maintain some kind of ordering of
  94. elements require specification of a comparison function upon which to
  95. base the ordering.  This is accomplished via a prototype file `defs.hP'
  96. that contains macros for these functions. While these macros default to
  97. perform reasonable actions, they can and should be changed in
  98. particular cases. Most prototypes require only one or a few of these.
  99. No harm is done if unused macros are defined to perform nonsensical
  100. actions. The macros are:
  101. `DEFAULT_INITIAL_CAPACITY'
  102.      The initial capacity for containers (e.g., hash tables) that
  103.      require an initial capacity argument for constructors.  Default:
  104.      100
  105. `<T>EQ(a, b)'
  106.      return true if a is considered equal to b for the purposes of
  107.      locating, etc., an element in a container.  Default: (a == b)
  108. `<T>LE(a, b)'
  109.      return true if a is less than or equal to b Default: (a <= b)
  110. `<T>CMP(a, b)'
  111.      return an integer < 0 if a<b, 0 if a==b, or > 0 if a>b.  Default:
  112.      (a <= b)? (a==b)? 0 : -1 : 1
  113. `<T>HASH(a)'
  114.      return an unsigned integer representing the hash of a.  Default:
  115.      hash(a) ; where extern unsigned int hash(<T&>).  (note: several
  116.      useful hash functions are declared in builtin.h and defined in
  117.      hash.cc)
  118.    Nearly all prototypes container classes support container traversal
  119. via `Pix' pseudo indices, as described elsewhere.
  120.    All object containers must perform either a `X::X(X&)' (or `X::X()'
  121. followed by `X::operator =(X&)') to copy objects into containers.  (The
  122. latter form is used for containers built from C++ arrays, like
  123. `VHSets'). When containers are destroyed, they invoke `X::~X()'.  Any
  124. objects used in containers must have well behaved constructors and
  125. destructors. If you want to create containers that merely reference
  126. (point to) objects that reside elsewhere, and are not copied or
  127. destroyed inside the container, you must use containers of pointers,
  128. not containers of objects.
  129.    All prototypes are designed to generate *HOMOGENOUS* container
  130. classes.  There is no universally applicable method in C++ to support
  131. heterogenous object collections with elements of various subclasses of
  132. some specified base class. The only way to get heterogenous structures
  133. is to use collections of pointers-to-objects, not collections of objects
  134. (which also requires you to take responsibility for managing storage for
  135. the objects pointed to yourself).
  136.    For example, the following usage illustrates a commonly encountered
  137. danger in trying to use conta