🚀 go-pugleaf

> someone wrote :
> > > I cannot see any logical argument why one of
> > >       a) unwinding the whole stack or
> > >       b) just terminating without unwinding it
> > > should be prefered by this principle.

>Unless the draft standard specifies that a call to
>"terminate" may ONLY be used for debugging purposes, it is
>both legal and likely for it to do something else, such as
>printing a message before exiting.

>Unless the standard is worded in such a way as to disallow
>the function passed to "set_terminate" below, I believe I
>have here an example of a program that could be used to
>detect such a difference in implementation.  Hence, one
>choice or another code be enforced (I have encoded my
>preferences into this test program's choice of PASS and
>FAIL).

I really can't see what's the connection between your message and example to the issue here.
The original question ( I believe ) was why it is un-specified in the standard whether the stack 
is unwind when terminate is called.

I gave a simple answer to this Q.
You can write whatever terminate/unexpected function you like. It really doesn't answer the Q.

It's a simple fact that if the standard commitee enforced "a", some people wouldn't be happy since 
they couldn't debug their programs as they used to.

>I believe I have here an example of a program that could be used to
>detect such a difference in implementation

The sample code you wrote just indicate ( detect ) whether or not the detructors are called, which 
is NOT that useful ...

This Q should be addressed by compiler vendors, when supplying a compiler + debugger. The commitee 
gave them the right to choose, just for implmenting a debugger.

And all this doesn't say that terminate "may ONLY be used for debugging purposes". A programmer 
can choose to exit that way from his program, if he likes that.

-- Etay Bogner,
-- ebogner@ird.scitex.com ( OLD ),
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.