This is the mail archive of the
mailing list for the libstdc++ project.
- To: dje at watson dot ibm dot com
- Subject: Re: PR3042
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Sun, 10 Jun 2001 02:00:31 -0700
- Cc: Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr, bkoz at nabi dot net, jason at cygnus dot com, libstdc++ at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <Gabriel.Dos-Reis@cmla.ens-cachan.fr><200106100053.UAA26388@makai.watson.ibm.com>
>>>>> "David" == David Edelsohn <email@example.com> writes:
David> I think we are debating what consistency means and
David> that Mark is brushing the issue under the rug with his
I think that's a little unfair. I'm not arguing consistency; I'm
arguing principle of least surprise, i.e., the behavior that is
easiest for users to understand.
I think the three options break down like this:
- Do no implicit instantations on platforms without COMDAT.
(This is my proposal).
Pros: Adding/removing initializers does not change behavior
Easy to document, explain.
In this sense, this is consistent.
Cons: Users have to write more explicit instantiations.
In some cases, users might have previously gotten
by with *no* explicit instantiations; now they have
to do some.
David has pointed out that this method makes the
affected platform less like GNU/Linux; the
non-availability of weak symbols is highlighted even
more than it would be otherwise.
- Jason's proposal: do no implicit instantiations only on platforms
without "working" COMMON. The pros and cons are exactly as above
on affected platforms -- but fewer platforms are affected. We
lose consistency between (say) AIX and other COMMON platforms --
but with my proposal we have already lost consistency between
AIX and ELF platforms, so that is a non-issue.
- David's proposal: use magic linker flags to make COMMON work.
Pros: Makes AIX work like other platforms with COMMON.
Cons: User confusion when different instantiations
are handled differently -- some require explicit
instantiation, some do not.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com