home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 7 / FreshFishVol7.bin / bbs / gnu / libg++-2.6-fsf.lha / libg++-2.6 / libg++ / NEWS < prev    next >
Text File  |  1994-07-13  |  23KB  |  536 lines
  1. SUMMARY OF RECENT MAJOR CHANGES to LIBG++.
  2. (Also check ../libio/NEWS.)
  3.  
  4. *** Major changes in libg++ version 2.6:
  5.  
  6. * There is a new set of bit*.c and bit*.h files in the src directory.
  7. This is a preliminary version of language-independent library for
  8. general low-level manipulation of bitstrings.  The BitString class
  9. has been (partially) re-written to use the new functions.
  10. (What kind of copyright to use for this library has not been
  11. decided yet.  It will at least be OK to treat it as LGPL code.)
  12.  
  13. *** Major changes in libg++ version 2.5:
  14.  
  15. * The iostream directory is gone.  It has been replaced by ../libio.
  16. The latter is a major re-write.  One major change is that libiostream.a
  17. (which is built in ../libio) can be used indendently of libg++,
  18. which is interesting because you may find its licensing conditions
  19. less onerous.  See ../libio/README.
  20.  
  21. Also, the guts of the code has been re-written in C instead of C++.
  22. This is so that you can build a C stdio implementation without
  23. a C++ compiler (as was needed before).  However, this is not 100% done.
  24.  
  25. * There is (preliminary) iostream manual (in ../libio/iostream.texi).
  26.  
  27. * The files in libg++/g++-include are now obsolete.  Instead, it
  28. is the compiler's responsibility to generate "fixed" copies of your
  29. existing C header files (such as /usr/include/stdio.h).  These copies
  30. (together with a g++ compiler modification) provide C++ access
  31. to the standard C library.  See the fixproto script in the gcc-2.5
  32. distribution.
  33.  
  34. *** Major changes in libg++ version 2.4:
  35.  
  36. * The configuration scheme has been largely re-vamped.
  37. Instead of the definitions that are common to all (or many) of
  38. the Makefiles being duplicated in each Makefile.in, they have
  39. now been moved into a shell script libg++/config.shared, which
  40. generates these standard definitions and rules.
  41.  
  42. Most of libg++/tests/Makefile, which had a lot of regularity,
  43. is now generated by the libg++/tests/Makefile.sh shell script.
  44.  
  45. Also libg++ no longer uses configure's 'subdirs' mechanism.
  46. Instead, it uses the 'configdirs' mechanism that most Cygnus
  47. packages use.  This means that each directory has its own
  48. configure.in, and each directory can be independently re-configured.
  49.  
  50. * Lots of fixes have been made so libg++ can be compiled by compilers
  51. other than g++ (specifically cfront), though there are still lots of
  52. warnings.  You may still have to edit some Makefiles etc; this
  53. will probably become easier in the next release.  Many of the
  54. changes involved not depending on g++ extensions.  However, some changes
  55. turned out to be that libg++ was depending on bugs in g++'s overload
  56. resolution.  These bugs in g++ are being fixed; this will cause some
  57. difficulties for libg++.  In some cases, we have decided that the
  58. cleanest fix is removing some libg++ functionality.  Specifically,
  59. the coersions Integer::operator long and Integer::operator double
  60. have been replaced by explicit methods Integer::as_long and
  61. Integer::as_double.  This means you may need to change your code.
  62. Please let us know if this is problematial.
  63.  
  64. *** Changes in libg++ version 2.3:
  65.  
  66. * iostream classes use multiple inheritance and virtual base classes.
  67. This is a little more complicated and slightly less efficient,
  68. but saves a slight amount of code duplication.  More importantly,
  69. it improves compatibility with other iostream implementations.
  70.  
  71. * A few of pseudo-template classes have been converted to use
  72. real templates.  The style used emphasizes sharing code for
  73. multiple template instatiations at the cost of somewhat more
  74. complex internal logic.  No promise is implied about when/if
  75. the remaining ones will be converted.  Using the template classes
  76. assumes gcc-2.3 or similar compiler.
  77.  
  78. * Added stdiobuf class which provides a streambuf wrapper around
  79. a stdio (FILE*).  This can be useful when mixing C and C++ code.
  80.  
  81. * streambuf sputn/sgetn virtuals have been made renamed to xsputn/xsgetn,
  82. and sputn/sgetn addedas inline methods.  This change is to be compatible
  83. with AT&T and ANSI; it could require changes to user code if you have
  84. written your own streambuf sub-classes.
  85.  
  86. * New utils/c++-mode.el (for editing C++ in emacs).
  87.  
  88. * Lots of little fixes all over.
  89.  
  90. *** Changes in libg++ version 2.2:
  91.  
  92. * Accurate input and output of floating-point numbers
  93.  
  94. * 'make clean' and its variants have been made more consistent.
  95.  
  96. * Improved portability (SVR4, NeXT, ...)
  97.  
  98.  
  99. *** Changes in libg++ version 2.1:
  100.  
  101. * "Class" include files in g++-include moved to src
  102.  
  103. Those include files that are just wrappers around C header files
  104. (e.g. signal.h) remain in g++-include, while the header files
  105. that are specific to libg++ (or C++) have been moved to src.
  106. If your system includes "C++-ready" C header files (as in SVR4 or
  107. Linux), you don't need to use the wrappers in g++-include.
  108.  
  109. * Portability
  110.  
  111. A lot of effort has gone into making libg++ more portable.
  112. Code that depends on internals of "traditional" implementations
  113. had been made more portable.  The 'libiberty' library is incorporated
  114. into libg++; this supplies (if needed) many functions that may be
  115. missing on particular hosts.
  116.  
  117. * Auto-configuration
  118.  
  119. New scripts automaticly figure out various properties of the
  120. system (and compiler) you use.  While these scripts are not
  121. foolproof, the intent is that on most systems you will no longer
  122. have to edit Makefiles or build special configuration files.
  123.  
  124. * Iostream bug-fixes
  125.  
  126. There have been numerous bug-fixes and enhancements in the
  127. iostream code.  Lots of rough edges in the streambuf and filebuf
  128. classes have been fixed.
  129.  
  130. There are still some rough edges of the protocol (as in what the
  131. streambuf class should do, and what sub-classes such as filebuf
  132. should handle).
  133.  
  134. * iostream enhancements for lexing/parsing.
  135.  
  136. You can now create a 'streammarker' object, which is a "remembered"
  137. position is a streambuf.  Later, you can backtrack to that position.
  138. This is supposed to work, even if the streambuf is unbuffered and
  139. otherwise unseekable, because the streambuffer never throws away
  140. any data following an extant streammarker.  This feature will be
  141. used to build various scanning/parsing facilities (with backup).
  142. (See iostream.texi for an example.)
  143.  
  144. * stdio library
  145.  
  146. Now supports all of ANSI's functionality.
  147.  
  148. *** Changes in libg++ version 2.0:
  149.  
  150. * iostream classes
  151.  
  152. The major change is that input/output uses the new iostream library.
  153. The design is based on (but not identical to) iostreams from
  154. AT&T C++ release 2.x, and the ANSI X3J16/WG21 draft C++ standard.
  155.  
  156. The iostream classes replace the old stream.  The new
  157. package provides some compatibility hooks.  Including the
  158. obsolete <stream.h> (or defining _STREAM_COMPAT) makes 
  159. more obsolete methods and features available.  However,
  160. you will probably have to change your code if you have used
  161. any libg++-specific extensions (such as the File class).
  162.  
  163. If you want stick with the old stream classes, change the
  164. definition of IO_DIR in Make.defs (to old-stream).  You will
  165. also need to 'make depend' in directories that contain depend,
  166. and then re-configure everything.  Note that the old-stream
  167. classes are *not* supported and *will* go away in a future release.
  168.  
  169. * Use g++ version 2 features (if available)
  170.  
  171. The main one is that an include file g++-include/FOO.h
  172. that is a wrapper for a standard C include file will now
  173. #include_next <FOO.h> instead of #include "/usr/include/FOO.h".
  174. This provides more flexibility wrt to using alternate C libraries
  175. (such as GNU libc), but it is not without its own problems.
  176. For example, if you compile libg++.a with a g++ that has old
  177. incompatible g++-include files in its path, these will be
  178. read (and then in turn read the /usr/include file).  If there
  179. are conflicts, you can remove the previously installed include files,
  180. or try something like 'make XTRAFLAGS=-I/usr/include' (or whatever
  181. include path gcc uses by default).
  182.  
  183. * Major Makefile changes.
  184. You can now 'make' from any subdirectory.
  185.  
  186. * Use of 'configure'.
  187.  
  188. * Copyrights changed to use the Library license version 2.0.
  189. (Some files have not been updated yet; we'll try to finish it for 2.1.)
  190.  
  191. * The prototype class SplayNode was put into a separate include file
  192. (g++-include/gen/SplayNode.hP).  This is to avoid duplication.
  193. It will require you to generate the appro