On Oct 30, 2013, at 9:15 AM, Marek Polacek <[email protected]> wrote:
> I admit I don't understand the cleanup_points very much and I don't
> know exactly where they are coming from
So, here is the mental model… and how it is related to the standard. C++
mandates that destructors for objects and temporary objects run no sooner than
a certain place, and no later than another place. In the implementation, we
choose a single point to run them, and use a cleanup point as the embodiment of
when destructors run. For example:
cleanup (a + cleanup (b - c))
means generate this:
a
b
c
-
dtors for things related to b-c
+
dtors for things related to a+ (b-c)
that's it. Pretty simple. Now, cute little details, once you get past the
simplicity, would be things like, if you run the cleanups for b-c, at the first
dtor line above, do you also run those same things at the lower point? That
answer is no, they only run once. If one takes an exception out of that
region, does the cleanup action run? That answer is yes. Lots of other
possible questions like this, all with fairly simple, easy to understand
answers. Just ask.
Now, some advanced topics… So, one thing you discover, if you _add_ a cleanup
point into an expression, it will run those actions sooner that they would have
run, if you had not. One cannot meet the requirements of the language standard
and just arbitrarily add cleanup points. However, constructs beyond the
language standard, say ({ s1; s2; s3; }) + b;, one discovers that the
implementation is free to decide if there is a cleanup point for ({ }) or not.
The language standard places no requirements on such code, and this is why we
can decide.
decl cleanups are strongly related to these sorts of cleanups, but lie just
outside (enclosing). I'll note their existence for completeness. See
CLEANUP_STMT for these.
