|
Boost : |
From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-09-30 04:16:46
Alan.Griffiths_at_[hidden] wrote:
>
> > -----Original Message-----
> > From: Alexander Terekhov [mailto:terekhov_at_[hidden]]
> > Sent: 26 September 2003 18:23
> >
> > SEH doesn't "violate" sequence points, AFAIK.
>
> I *think* I've seen it happen - but it has been a while since I've been
> spelunking in this technology and it may be that I've either misremembered
> or jumped to an incorrect conclusion. But it seems implausible: SEH can
> arise from fetch or store which are often resequenced - so this would
> restrict the available optimisations.
Raising SEH exception (or signal) is clearly a *side effect* (that
isn't "covered" by the C/C++ standard... unless it comes "on top"
of accessing an object designated by a volatile lvalue or modifying
an object, "calling a library I/O function, or calling a function
that does any of those operations" aside for a moment). As such,
implementations are indeed kinda constrained in what they can do
with respect to reordering of operations that can raise SEH or
synchronous signals (unless they can prove that reordering doesn't
impact "handling")
>
> Anyway, I've never seen any MS documentation that would support this belief.
> (And a quick search of MSDN doesn't return any promising hits.) Do you have
> a reference?
Nope. But I'd consider it simply "a bug" if they don't do it right.
>
> > > What advantage does that bring?
> >
> > Long story. Sorry. I can drop some links. Interested?
>
> Yes.
http://www.google.com/groups?th=f98e4fa7052aa25b
(Subject: __attribute__((cleanup(function)) versus try/finally)
http://www.google.com/groups?th=c41b1edf07790c28
(Subject: Exception handling... it's time to fix the standard)
http://www.google.com/groups?th=94e63c7613727eec
(Subject: std0X::expected_exception<T>())
http://www.google.com/groups?th=236c96ebdd0891c3
(Subject: Re: std0X::expected_exception<T>() [repost])
regards,
alexander.
-- http://www.sco.com/ibmlawsuit/ibmamendedcounterclaims.pdf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk