home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / gnu / gcc / help / 2894 < prev    next >
Encoding:
Text File  |  1993-01-11  |  2.1 KB  |  49 lines
  1. Newsgroups: gnu.gcc.help
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!gatech!destroyer!fmsrl7!lynx.unm.edu!zia.aoc.nrao.edu!laphroaig!cflatter
  3. From: cflatter@nrao.edu (Chris Flatters)
  4. Subject: Re: SUGGESTION: Include libg++ in the next
  5. Message-ID: <1993Jan11.190930.17524@zia.aoc.nrao.edu>
  6. Sender: news@zia.aoc.nrao.edu
  7. Reply-To: cflatter@nrao.edu
  8. Organization: NRAO
  9. References: <amos.726773731@sol>
  10. Date: Mon, 11 Jan 93 19:09:30 GMT
  11. Lines: 36
  12.  
  13. In article 726773731@sol, amos@sol.acs.unt.edu (Amos A. Gouaux) writes:
  14. >keith@msmri.med.ubc.ca writes:
  15. >>
  16. >> Since gcc-lib is included in gcc-2.3.2 why not include g++-lib
  17. >> in future releases of gcc.  This would make installation of gcc 
  18. >> much easier.
  19. >>
  20. >
  21. >problem is the size of the source.  this would be a massive package.
  22. >for those not interested in c++, this size might be a real hindrance,
  23. >particularly on systems with limited space.
  24. >
  25. >although, perhaps one approach would be to have two gcc packages, one
  26. >with libg++ and one without.  the way libg++ is distributed, seems
  27. >like this would be rather easy to facilitate.  the configure step
  28. >could apply to both.  with libg++, it almost looks like this might be
  29. >an eventual goal.  could this be the case?
  30.  
  31. It might make sense to distribute the <iostream.h> package with gcc
  32. and to retain the container and utility classes (which make up the
  33. bulk of libg++) as a separate distribution.
  34.  
  35. Rationale:
  36.  
  37. Most C++ programs/packages use iostreams and there is pretty good agreement
  38. on what the iostreams package should look like.  On the other hand there
  39. are a variety of container/utility class libraries available (eg. COOL,
  40. the USL standard components, the Booch components) and the monolithic
  41. nature of libg++ often makes it difficult to incorporate components from
  42. other libraries due to naming clashes (there is also a notorious naming
  43. clash between the GNU String class and a typedef used in Xt).  I think that
  44. there is a good case for splitting libg++ up even if the streams package
  45. were not distributed with gcc.
  46.  
  47.     Chris Flatters
  48.     cflatter@nrao.edu
  49.