This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Implications of tighter integration of libg++
- To: martin at mira dot isdn dot cs dot tu-berlin dot de (Martin von Loewis)
- Subject: Re: Implications of tighter integration of libg++
- From: hjl at lucon dot org (H.J. Lu)
- Date: Mon, 9 Feb 1998 16:44:57 -0800 (PST)
- Cc: jbuck at synopsys dot com, law at cygnus dot com, rittle at comm dot mot dot com, egcs at cygnus dot com
>
> > say "using namespace std;" as that imports all names. Rather, just
> > things like
> >
> > using std::istream;
> > using std::ostream;
> > using std::cin;
> > using std::cout;
> > using std::cerr;
>
> This does not solve the problem I'm talking about. With that scheme,
> and the implementation of namespace I have in mind, names would still
> come out as Q23std7istream, rather than 7istream as they do now. This
> is because the compiler would always resolve names to the place where
> they are actually introduced, regardless of any using and typedef
> magic applied.
>
> So, even if old sources would still compile, old objects would not
> link anymore. This is especially bad in presence of shared libraries
> which have to accomodate both sets of header files.
That can be done via symbol alias.
>
> Therefore, I think there is some value to the proposal of installing
> libg++ in the compiler-specific directories.
>
I think that is no good. It is the same as make libgcc shared.
--
H.J. Lu (hjl@gnu.org)