This is the mail archive of the
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
- From: "David Abrahams" <david dot abrahams at rcn dot com>
- To: "Mark Mitchell" <mark at codesourcery dot com>,"Martin v. Loewis" <martin at v dot loewis dot de>
- Cc: "Jason Merrill" <jason at redhat dot com>,"Ralf W. Grosse-Kunstleve" <rwgk at cci dot lbl dot gov>,<gcc at gcc dot gnu dot org>
- Date: Sun, 12 May 2002 14:12:51 -0500
- Subject: Re: Minimal GCC/Linux shared lib + EH bug example
- References: <email@example.com> <firstname.lastname@example.org>
- Reply-to: "David Abrahams" <david dot abrahams at rcn dot com>
----- Original Message -----
From: "Martin v. Loewis" <email@example.com>
> > We will have given people a bigger bazooka, but it will be aimed at
> > their own feet.
> Since the alternative is not to allow writing exceptions in C++,
"extensions", I think---------------------------^^^^^^^^^^
> people would be willing to accept restrictions, if they know what
> those restrictions are.
Yes. All we need is a well-documented model that can be made to work.
> Requiring all classes used as exceptions to be
> polymorphic (non-pure non-inline blabla)
That's pushing it. I *might* get away with requiring that for my
application, but if my customers accept that restriction it will only be
> and not allowing static
> members in templates might be acceptable
!! absolutely not acceptable !!
Do you really mean "not allowing", here? The use of static members in
templates (known to probably not be shared) is one of the primary ways I
get around the problems we're discussing. I routinely declare static
reference members and initialize them through function calls to my shared
library. Once static initialization is done, they all refer to the right
piece of data. If I couldn't do that, I'd be royally shafted.
> ; not allowing exceptions
> probably isn't.
Right. Also, let me point out that exceptions and RTTI deserve special
treatment because workarounds like the one described above are not