I don't want to be picky but I feel one shouldn't pack too much
into one thing and in a way break the logic flow and possibly
introduce limitations.
The basic rule is to clean up in the destructor what has been
allocated/aquired in the constructor - and this shouldn't be
interrupted but stay that way.
What you want to address, if I got it right (If not, I apologize
for my interruption) is the problem of incoherent state, i.e.
(relating to your example) to have res1 and res2 aquired but not
res3.
In my (possibly strongly limited) understanding scope(failure) is
the right approach.
Having a mechanism (as suggested) that also takes care of the
dtor's job breaks the normal logic and might create new problems
or limitations by implicitly putting a dtor job into a ctor
mechanism.
What, for instance, if I aquire 10 resources in ctor and during
normal programm execution cleanup 7 of them, so only some are
left for dtor?
If scope(failure) does already work in ctor, just keep it that
way. If not,HS Teoh's idea to make it work is great. But that
about it. Don't add more functionality in it. Normal ctor/dtor
working should be kept and so should scope(). Whatever user wants
beyond that can be coded by him. Don't break major flow for some
luxury (having scope in ctor isn't luxury, having it reach into
dtor, too up to the point of making dtor superflous is).
scope is a brilliant feature. But I feel we shouldn't have it do
"miracles", even less behind curtains.
In case what I said is just plain stupid and I should have shut
up as newbie, I apologize and won't disturb any more.
