Subject: Re: Points raised on EWG reflector
From: Victor Luchangco (victor.luchangco.work_at_[hidden])
Date: 2020-09-28 11:53:46
On Tue, Sep 22, 2020 at 4:44 PM Michael L. Scott via SG5 <
> On Sep 22, 2020, at 12:26 PM, Hans Boehm via SG5 <sg5_at_[hidden]>
> > EWG reflector discussions raised another couple of points, which I had
> lost track of:
> > Tony Van Eerd pointed out that we probably want exceptions escaping from
> a transaction to be UB rather than implementation defined, since the
> semantics have been regularly debated. We don't really want some
> implementations supporting commit, and others abort semantics. Code just
> shouldn't rely on that. I tend to agree with that observation.
> I agree as well.
Sorry to jump on this so late:
What is the functional difference between "undefined behavior" (I assume
this is what UB stands for) and "implementation defined"?
Presumably, a particular implementation can implement "undefined behavior"
however it likes, and in particular, it can do so in a predictable
and understandable way. Does saying that behavior is
implementation-defined create an onus on implementors to actually give
semantics to a feature? (I agree that we do not want to create any such
> > There was also discussion of somehow providing a capture list for
> transactions, as in lambda's. I'm less confident I understand that proposal.
> Interesting. Perhaps the idea is that the code should explicitly document
> what it is that the transaction touches? Thatâs a tempting idea, but
> probably not as useful as one might hope for linked data structures, where
> what may be modified is the _reach_ of the capture.
I agree that this is interesting, but it raises issues that I think it's
better to avoid for now, if we can.
> > Hans
> > --
> > SG5 mailing list
> > SG5_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg5
> SG5 mailing list
SG5 list run by email@example.com
Older Archives on Google Groups