This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PR3042
- To: Jason Merrill <jason_merrill at redhat dot com>
- Subject: Re: PR3042
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Mon, 11 Jun 2001 11:12:18 -0700 (PDT)
- 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>
This is my last response to this thread.
> You mean, they don't use static data member templates?
That is my understanding. Perhaps I'm off.
> 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?
v3 uses a lot of const static data members, and static data members, so
it's common enough for me.
;)
> ...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.
Yep.
Also, we should add some kind of symbol versioning (at this point, we
should export all the v3 symbols with version info via a linker script.)
I don't suppose anybody is up for this? Or explaining to me how it's
done (Uli mentioned this last week, but I'm still a bit in the dark as
to how it's done.) This will make transitioning from 3.0 to 3.1 easier.
Then again, the headers should probably be versioned as well. (As per
Gaby's thought last week.)
Oh well. I punt.
-benjamin