This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] C++ vs forced unwinding
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: jason at redhat dot com, mark at codesourcery dot com, gcc-patches at gcc dot gnu dot org
- Date: Wed, 2 Apr 2003 09:56:54 -0600
- Subject: Re: [RFC] C++ vs forced unwinding
- References: <20030401021229.GA6277@twiddle.net><wvlistxaol7.fsf@prospero.boston.redhat.com><20030401134858.A1484@twiddle.net>
>We could. Does that make more or less sense than being able to
>call a cancellation point from a function declared throw(int)?
Less.
I think the cancellation point stuff should be done orthogonally to
exceptions, at least as described to the end-user. Trying to make C++
exception specifications fit into what you describe as
"not-an-exception" is not going to work, unless you come up with
specific extension C++ syntax that means "don't even throw what RTH is
calling a "not-an-exception."
As it stands, throw() means no exceptions are thrown, ie no throw(*)
statements in the codepath. It says nothing about the the synthetic
throwing of implicit cleanups.
Thus, exception specifications don't include it, so throw() or
throw(int) would both mean that there could be no C++ exceptions, or
only ints thrown respectively, and then both might have "forced
unwinding from a not-an-exception that runs only cleanups" running
amuck. Or, not amuck, but you get the idea.
Again, I urge you to spend ten minutes or so trying to think about a way
to make "C" shared libraries callable from C++ with less work and
thought for end users than a recompilation with yet another new and
mysterious gcc flag. It was really nice when this became something that
"just worked," and it would be a shame to lose this.
-benjamin