This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimal GCC/Linux shared lib + EH bug example

----- Original Message -----
From: "Martin v. Loewis" <>

> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]