🚀 go-pugleaf

In article 726773731@sol, amos@sol.acs.unt.edu (Amos A. Gouaux) writes:
>keith@msmri.med.ubc.ca writes:
>>
>> Since gcc-lib is included in gcc-2.3.2 why not include g++-lib
>> in future releases of gcc.  This would make installation of gcc 
>> much easier.
>>
>
>problem is the size of the source.  this would be a massive package.
>for those not interested in c++, this size might be a real hindrance,
>particularly on systems with limited space.
>
>although, perhaps one approach would be to have two gcc packages, one
>with libg++ and one without.  the way libg++ is distributed, seems
>like this would be rather easy to facilitate.  the configure step
>could apply to both.  with libg++, it almost looks like this might be
>an eventual goal.  could this be the case?

It might make sense to distribute the <iostream.h> package with gcc
and to retain the container and utility classes (which make up the
bulk of libg++) as a separate distribution.

Rationale:

Most C++ programs/packages use iostreams and there is pretty good agreement
on what the iostreams package should look like.  On the other hand there
are a variety of container/utility class libraries available (eg. COOL,
the USL standard components, the Booch components) and the monolithic
nature of libg++ often makes it difficult to incorporate components from
other libraries due to naming clashes (there is also a notorious naming
clash between the GNU String class and a typedef used in Xt).  I think that
there is a good case for splitting libg++ up even if the streams package
were not distributed with gcc.

	Chris Flatters
	cflatter@nrao.edu