On Oct 30, 2013, at 9:15 AM, Marek Polacek <pola...@redhat.com> 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.