|
Boost : |
From: Alan.Griffiths_at_[hidden]
Date: 2003-09-26 09:09:05
> -----Original Message-----
> From: Alexander Terekhov [mailto:terekhov_at_[hidden]]
> Sent: 26 September 2003 00:05
>
> Gennadiy Rozental wrote:
> [...]
> > 1. Does SEH is an async exception?
>
> No.
Compared to C++ exceptions there are fewer guarantees regarding which
effects have completed of a C++ statement in which a SEH exception occurs.
(To the extent that is may be impossible to predict which statements will
have completed.)
> > 4. How the technique described in Dave A. article helps to
> resolve a problem
> > discussed in items 3?
>
> Dave A. should better fix the C++ std instead of hacking with MS SEH.
Dave has done something practical about the co-existance of two conflicting
exception handling technologies. That is more than most of us - and I for
one find his work very useful. Dave is not responsible for the current
situatuation. IMO If anyone should be fixing anything it should be MS.
> > 5. What would be an ideal behavior?
>
> A) WG21 mandates 2-phase EH
What advantage does that bring?
>
> -and-
>
> B) MS translates SEH to C++ exceptions "by default" (in C++ appls).
That way lies madness!
SEH exceptions can arise in "nothrow" code - this can invalidate the
programmer's assumptions about the state of the program. Should that
happen, the last thing that is useful is to treat it as a C++ exception -
implying that the program is in a stable state.
It is conceiveable that a model in which C++ exceptions are a specialisation
of SEH exceptions is viable, but not, as you suggest, the converse.
-- Alan Griffiths http://www.octopull.demon.co.uk/ ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk