This is the mail archive of the gcc-patches@gcc.gnu.org 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: [RFC] C++ vs forced unwinding


>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


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