cleanups: next steps

[Doug Evans <dje at google dot com>]

On Fri, Apr 13, 2012 at 11:16 AM, Doug Evans <dje@google.com> wrote:
> On Fri, Apr 13, 2012 at 10:53 AM, Tom Tromey <tromey@redhat.com> wrote:
>> Though I'd still prefer that most
>> code not play games with cleanups at all and just treat them as
>> block-scoped as much as possible.
>
> cleanups are chained, and one has to always be cognizant of the chain
> (in a not-entirely intuitive fashion IMO, though I understand the
> implementation reasons for it).
> I think there's value in a cleanup mechanism where one didn't have to
> be cognizant of the chain, or at least be less cognizant (whether
> that's completely possible, I don't know).
>
> [btw, I don't know if I'd color it as "playing games" ...]

btw, this is why I like nullify_cleanup:  I can discard a cleanup
without having to be cognizant of the chain, with discard_cleanups I
have to understand the entire function, not just the cleanup I'm
interested in.  I think that would be more robust in the face of
changes to the function.  But I can also understand not wanting to
extend the API.

I was thinking, IWBN if cleanups were recorded differently so that the
result of make_cleanup was the handle of that cleanup.  I think the
intuitive sense of cleanups would go up, and that could lead to fewer
issues.  [I don't know that it would, but I like the improvement in
sensibility of what the result of make_cleanup is.]

I was trying to think of a good use of gcc's cleanup attribute (as
only a correctness checking mechanism since it's non-portable).
Nothing came to mind.