Re: [boost] [scope_guard] New revision available + naming consideration
I sent this earlier but it never showed up on the list.
By the way, that might work well for smart pointers; why don't shared_ptr and friends use this idiom?
Maybe because it allows more than a literal zero?
I personally like the guard/dismiss names, they are reminiscent of commands you would give a real guard. 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. Jason Stewart
On Thu, 22 Sep 2005 15:54:31 -0400, Jason Stewart <jstewart@pobox.com> wrote:
By the way, that might work well for smart pointers; why don't shared_ptr and friends use this idiom?
Maybe because it allows more than a literal zero?
I personally like the guard/dismiss names, they are reminiscent of commands you would give a real guard.
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.
I don't think this will work well, because the guard could be fairly complex. I'd hate to have several identical multi-line guard statements in one function. -- Be seeing you.
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.
I don't think this will work well, because the guard could be fairly complex. I'd hate to have several identical multi-line guard statements in one function.
I had not thought of that because it never occurred to me that one would create a guard, dismiss it, then reactivate it. Would people really reactivate it that often after dismissing it? I was thinking more of the case where you do not know when you create the guard whether or not you will need to activate it. Jason Stewart
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.
I don't think this will work well, because the guard could be fairly complex. I'd hate to have several identical multi-line guard statements in one function.
I had not thought of that because it never occurred to me that one would create a guard, dismiss it, then reactivate it. Would people really reactivate it that often after dismissing it?
I was thinking more of the case where you do not know when you create the guard whether or not you will need to activate it.
The more common use case is to create initially disabled guard and then, depending on some condition, activate it. I've had the need of such functionality several times.
Jason Stewart <jstewart@pobox.com> writes:
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
reset() is wrong unless you mean the guard to immediately take it would take upon destruction. release() would be the correct smart pointer analogy.
} }
-- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Jason Stewart <jstewart@pobox.com> writes:
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.
reset() is wrong unless you mean the guard to immediately take it would take upon destruction. release() would be the correct smart pointer analogy.
I don't really think that smart pointers analogies are applicable in the first place. The guard is not a pointer, so let's not confuse users with such parallels.
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.
Since in current implementation scope_guard is a typedefed reference the example above will not work. Besides, I don't really like the idea to create the whole object just to change the status. In addition, the code readability suffers.
participants (4)
-
Andrey Semashev -
David Abrahams -
Jason Stewart -
Thore Karlsen