Re: signal handling and (structured) exception handling
On Oct 12, 7:57 pm, Peter <excessph...@gmail.com> wrote:
On Oct 12, 5:10 am, James Kanze <james.ka...@gmail.com> wrote:
I don't know of any machine which can't support virtual
functions. Even today, however, machines which can raise an
asynchronousexceptionare rare.
The first CPU I came in contact with (Z80) did not have any
feature to call via a pointer stored somewhere -- it could
call only to a fixed address. Maybe you could emulate it via
manipulating the stack and executing return.
The instruction set of the Z80 was a superset of that of the
8080, and the languages I used on the 8080 certainly supported
indirect calls. I think that they did simply push the address
onto the stack, and then do a ret; another alternative would
have been modifying the address in a jmp instruction; not very
thread safe, but that was never an issue on an 8080.
The standard could simply claim, that on machines which
support memory protection, a C++ exception should be thrown
instead of a signal. This would cover all of the platforms I
have to deal with (various UNIXs and Windows).
Except that this can't be made to work under Solaris, on a
Sparc. And more generally, the fact that C++ doesn't throw an
exception in such cases is a major reason why people continue to
use it---if there is an error in your code, an exception is the
last thing you want. (A C++ exception, anyway, with destructors
being called.)
--
James Kanze