From: Jason Stewart <jstewart@pobox.com>
However, maybe using the shared_ptr semantics would work. I.e. if you can create a guard that is "uninitialized" and then reset it later to an active guard.
{ scope_guard g;
if (some condition) { g = scope_guard(my_undo_function); // do something here }
if (some other condition) { // we changed our mind, dismiss it. g = scope_guard;
// or ... // g.dismiss(); // g.reset(); // like shared_ptr } }
It seems to me that is as easy to read as having an explicit "guard" or "activate" command is. I confess though that I didn't follow the early discussion closely so I apologize is this has been discussed already.
You're missing the usage of wanting to keep the original undo behavior, ignore it in some portion of the code, and then reinstate it later. With the above, it appears that would entail this sort of usage: scope_guard g(my_undo_function); ... g = scope_guard(); ... g = scope_guard(my_undo_function); ... That introduces a maintenance problem. With the names we're discussing, you'd write this instead: scope_guard g(my_undo_function); ... g.dismiss(); // or whatever name is selected ... g.protect(); // or whatever name is selected ... -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;