This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PR3042
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: PR3042
- From: Jason Merrill <jason_merrill at redhat dot com>
- Date: 11 Jun 2001 18:43:04 +0100
- Cc: Mark Mitchell <mark at codesourcery dot com>, Phil Edwards <pedwards at disaster dot jaj dot com>, "dje at watson dot ibm dot com" <dje at watson dot ibm dot com>, "Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr" <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- References: <Pine.SOL.3.91.1010611091036.26630E-100000@taarna.cygnus.com>
>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:
>> > Seconded. The more I hear about the quirks of AIX linking semantics
> Yup. As much as I hate to keep this thread alive, I think the KDE and Qt
> arugments advanced by David for keeping the same semantics as gcc.2.95.x
> (which, IMHO, are broken) are a bit of a red herring: yes, these programs
> are written in c++, but they don't really use the kinds of data
> structures that have the difficulty.
You mean, they don't use static data member templates?
I don't see how you can consider the 2.95 semantics "broken". They are
more conformant than Mark's proposal, in that more valid code can be
compiled. The question is, how common is code which is accepted under the
status quo that would not be accepted under Mark's proposal? Is it common
enough to justify the extra complexity in the compiler and for users?
I believe that the extra complexity for users is negligible. I've
certainly never heard a complaint about it in practice. I imagine that
most people using affected platforms are using -fno-implicit-templates or
-frepo already, or just not using templates. Of course, that last will
probably change with template iostreams...which reminds me--we should tag
the standard instantiations provided in the library as 'extern template' so
that we don't do extra work generating redundant copies. Maybe in 3.0.1.
WRT the extra complexity in the compiler, I have a rewrite of the linkage
code under way that should simplify this stuff significantly.
> That being said, at this point, now that most things are working, I'd
> hate to see a significant linkage change at the last minute.
Yes.
Jason