[scope_guard] New revision available + naming consideration
The new version is available in the Sandbox (I moved it into Function objects): http://boost-consulting.com/vault/index.php?action=downloadfile&filename=scope_guard.zip&directory=Function%20Objects& Here is a shord summary about changes: - Various cosmetic changes, including macro and function names. - Exception support code (with_catcher policy) moved into a separate file. - Added a helper function "catching" to simplify use of with_catcher policy. - Unique names generating code moved into a separate file. By the way, maybe this code should better be in Boost.Preprocessor? See boost/guard/unique_names.hpp. - Revised the guard_ptr class, moved it up to boost namespace. It is now resided in guard_ptr.hpp. - The actions_trace class was considered to be too specific and was eliminated. The new guard_adapter class is supposed to expand the functionality of holding scope guards in containers to every STL-compatible container (sequental or associative) and even to the standard container wrappers such as stack, queue or priority_queue. See guard_adapter.hpp for more details. - I hope I've fixed problems with VC6 (and even maybe BCB) I've been reported, but I can't tell for sure since I can't try it. At least the code that uses scope_guard.hpp should work (once again, I hope). Maybe I'll have a chance to test it on VC6 in a week or two, but now I'm walking blindly. As always, I've tried it on VC7.1, ICL9 and MinGW (GCC 3.4.4). Few words about what I'm concerned about: - The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this. - The naming of the function make_guarded_call (in previous version it was make_transaction) is what I'm not sure of. This function in addition to a scope_guard creation calls some another functor. The semantic is grouping the "do" and "undo" actions in the user code. Does anyone have a better name? - I have received a proposal of ability to allocate space for several scope_guards on the stack. In current implementation when using guard_adapter and guard_ptr with some container the guard objects will be allocated in the heap which might be slightly slower than if it would be on the stack. So the most probable implementation of such proposal shall be a separate static container. Does anyone have any thoughts about this? How much would you need such functionality? I think, I've reached some point release (unless anyone have proposal about namings). At least, the main scope guard implementation seems to be stable. So I would like to check in this version to CVS (or, maybe, if someone do this for me) if there are no arguments against this. Once I have done this I could start making BoostBook docs (now there are only doxygen-like comments in the code) and make some unit tests.
From: "Andrey Semashev" <andysem@mail.ru>
I've not looked at anything else, but I thought I'd address these:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
"Dismiss" would be the right word in English to tell the guard to go away and do nothing more.
- The naming of the function make_guarded_call (in previous version it was make_transaction) is what I'm not sure of. This function in addition to a scope_guard creation calls some another functor. The semantic is grouping the "do" and "undo" actions in the user code. Does anyone have a better name?
How about "call_guarded" or "invoke_guarded?" -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: "Andrey Semashev" <andysem@mail.ru>
I've not looked at anything else, but I thought I'd address these:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
"Dismiss" would be the right word in English to tell the guard to go away and do nothing more.
Yes but what about its antipod - a function to enable the guard? Note that the guard may even be initially disabled (that's another reason I didn't like dismiss) and then it may be enabled in some place.
- The naming of the function make_guarded_call (in previous version it was make_transaction) is what I'm not sure of. This function in addition to a scope_guard creation calls some another functor. The semantic is grouping the "do" and "undo" actions in the user code. Does anyone have a better name?
How about "call_guarded" or "invoke_guarded?"
That might do. But doesn't the common make_ prefix mean that something (a guard in this case) should be created?
From: "Andrey Semashev" <andysem@mail.ru>
Rob Stewart wrote:
From: "Andrey Semashev" <andysem@mail.ru>
I've not looked at anything else, but I thought I'd address these:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
"Dismiss" would be the right word in English to tell the guard to go away and do nothing more.
Yes but what about its antipod - a function to enable the guard? Note that the guard may even be initially disabled (that's another reason I didn't like dismiss) and then it may be enabled in some place.
I see. I thought you somehow knew of "dismiss" in another language and didn't know the English word for it. I think Markus is right: summon is the opposite of dismiss for a guard. The question is whether it reads well when used: guard g; if (something) g.dismiss(); ... if (whatever) g.summon();
- The naming of the function make_guarded_call (in previous version it was make_transaction) is what I'm not sure of. This function in addition to a scope_guard creation calls some another functor. The semantic is grouping the "do" and "undo" actions in the user code. Does anyone have a better name?
How about "call_guarded" or "invoke_guarded?"
That might do. But doesn't the common make_ prefix mean that something (a guard in this case) should be created?
I took your question to mean that you were naming a function template that created a guard, called a function (object), and then destroyed the guard. Now it sounds as though you're creating a function object that does that and you want to name the function template that creates the function object. In that case, "make_guarded_caller" sounds about right. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: "Andrey Semashev" <andysem@mail.ru>
Rob Stewart wrote:
From: "Andrey Semashev" <andysem@mail.ru>
I've not looked at anything else, but I thought I'd address these:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
"Dismiss" would be the right word in English to tell the guard to go away and do nothing more.
Yes but what about its antipod - a function to enable the guard? Note that the guard may even be initially disabled (that's another reason I didn't like dismiss) and then it may be enabled in some place.
I see. I thought you somehow knew of "dismiss" in another language and didn't know the English word for it.
I think Markus is right: summon is the opposite of dismiss for a guard. The question is whether it reads well when used:
guard g; if (something) g.dismiss(); ... if (whatever) g.summon();
"Guard"? Somehow "Summon" doesn't read very well above. I'm sorta partial to guard, but this may cause confusion with both the class name and the namespace name? scope_guard g; if(cond) g.dismiss(); ... if(cond2) g.guard(); Just a thought... -- /Brian Riis
Brian Ravnsgaard Riis wrote:
Rob Stewart wrote:
I think Markus is right: summon is the opposite of dismiss for a guard. The question is whether it reads well when used:
guard g; if (something) g.dismiss(); ... if (whatever) g.summon();
"Guard"? Somehow "Summon" doesn't read very well above. I'm sorta partial to guard, but this may cause confusion with both the class name and the namespace name?
scope_guard g; if(cond) g.dismiss(); ... if(cond2) g.guard();
Just a thought...
I agree the "guard" is better. But the variable type name is scope_guard, many scope guard tools are resided in boost::guard namespace, the function for creating guards is make_guard. Aren't there too much guards here?
Andrey Semashev wrote:
Brian Ravnsgaard Riis wrote:
Rob Stewart wrote:
I think Markus is right: summon is the opposite of dismiss for a guard. The question is whether it reads well when used:
guard g; if (something) g.dismiss(); ... if (whatever) g.summon();
"Guard"? Somehow "Summon" doesn't read very well above. I'm sorta partial to guard, but this may cause confusion with both the class name and the namespace name?
scope_guard g; if(cond) g.dismiss(); ... if(cond2) g.guard();
Just a thought...
I agree the "guard" is better. But the variable type name is scope_guard, many scope guard tools are resided in boost::guard namespace, the function for creating guards is make_guard. Aren't there too much guards here?
Yes, probably. As I said, just a thought... -- /Brian Riis
Brian Ravnsgaard Riis <brian@riis.as> writes:
Andrey Semashev wrote:
Brian Ravnsgaard Riis wrote:
Rob Stewart wrote:
I agree the "guard" is better. But the variable type name is scope_guard, many scope guard tools are resided in boost::guard namespace, the function for creating guards is make_guard. Aren't there too much guards here?
Yes, probably. As I said, just a thought...
I don't care how large the population of guards is, if "guard" is the right name. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: Brian Ravnsgaard Riis <brian@riis.as>
Andrey Semashev wrote:
Brian Ravnsgaard Riis wrote:
Rob Stewart wrote:
I think Markus is right: summon is the opposite of dismiss for a guard. The question is whether it reads well when used:
guard g; if (something) g.dismiss(); ... if (whatever) g.summon();
"Guard"? Somehow "Summon" doesn't read very well above. I'm sorta
It also occurs to me that "summon" doesn't really convey that the guard is being asked to do something. It merely asks the guard to come before the caller.
partial to guard, but this may cause confusion with both the class name and the namespace name?
scope_guard g; if(cond) g.dismiss(); ... if(cond2) g.guard();
I agree the "guard" is better. But the variable type name is scope_guard, many scope guard tools are resided in boost::guard namespace, the function for creating guards is make_guard. Aren't there too much guards here?
When thinking of someone yelling, "Guard!" this fits pretty well, but it can just as easily be thought of as an accessor. Still, one has to know what a scope_guard is to understand "dismiss" or "guard," so the name is still quite reasonable. What about "post?" That is, you're "posting a guard." You can post a guard after you dismiss him, by implicitly summoning him, of course. In this case, the guard never went away, he was just told to ignore his charge by dismiss(). Thus, he needn't be summoned. scope_guard g; if (a) g.dismiss(); ... if (b) g.post(); Perhaps if the member function were named "guarding" and it took a bool, and you provided non-member functions dismiss() and post(), this might read better: scope_guard g; if (a) dismiss(g); ... if (b) post(g); dismiss(g) would, of course call g.guarding(false), whereas post(g) would call g.guarding(true). -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"Rob Stewart" <stewart@sig.com> wrote in message news:200509221407.j8ME7elF003986@shannonhoon.balstatdev.susq.com...
From: Brian Ravnsgaard Riis <brian@riis.as>
Andrey Semashev wrote:
Brian Ravnsgaard Riis wrote:
Rob Stewart wrote:
I think Markus is right: summon is the opposite of dismiss for a guard. The question is whether it reads well when used:
guard g; if (something) g.dismiss(); ... if (whatever) g.summon();
"Guard"? Somehow "Summon" doesn't read very well above. I'm sorta
[snip]
When thinking of someone yelling, "Guard!" this fits pretty well, but it can just as easily be thought of as an accessor. Still, one has to know what a scope_guard is to understand "dismiss" or "guard," so the name is still quite reasonable.
What about "post?" That is, you're "posting a guard." You can post a guard after you dismiss him, by implicitly summoning him, of course. In this case, the guard never went away, he was just told to ignore his charge by dismiss(). Thus, he needn't be summoned.
scope_guard g; if (a) g.dismiss(); ... if (b) g.post();
Perhaps if the member function were named "guarding" and it took a bool, and you provided non-member functions dismiss() and post(), this might read better:
scope_guard g; if (a) dismiss(g); ... if (b) post(g);
Carrying the analogy to the extreme: scope_guard g; if (a) at_ease(g); ... if (b) attention(g); // emphasizing the appropriate syllables! :o) Jeff
From: "Jeff Flinn" <TriumphSprint2000@hotmail.com>
scope_guard g;
if (a) at_ease(g); ... if (b) attention(g); // emphasizing the appropriate syllables!
Interesting. "At ease" avoids the notion that "dismiss" raises of the guard no longer being around. It suggests that the guard isn't paying attention. Unfortunately, I don't think "at_ease" reads all that well in the code. One usually doesn't tell code to "take it easy" or "chill" for a while, at least not in so many words. It just sounds strange to me. So, if you choose to keep "dismiss," which really does seem like a nice choice, what is a good antonym? An interesting near antonym is "muster:" scope_guard g; if (a) g.dismiss(); ... if (b) g.muster(); A variation on "guard" (the verb) is "protect," which has the right meaning and avoids overloading the word "guard" to excess: scope_guard g; if (a) g.dismiss(); ... if (b) g.protect(); "Secure" is another choice. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"Rob Stewart" <stewart@sig.com> wrote in message news:200509221937.j8MJbHGp014463@shannonhoon.balstatdev.susq.com...
A variation on "guard" (the verb) is "protect," which has the right meaning and avoids overloading the word "guard" to excess:
scope_guard g; if (a) g.dismiss();
if (a) g.ignore(); To me dismiss has much more heavy handed connotations.
... if (b) g.protect();
"Secure" is another choice.
Either of these pair well. Just a thought, has g.on() and g.off() been considered? Jeff
Just a thought, has g.on() and g.off() been considered?
Yes, quite a good variant. I remember, I thought of it when I began writing my implementation, but later I used the verbs arm and disarm.
I might be way too late for this train, but just to add another suggestion to the bowl - how about observe/overlook? And if not, then FWIW dismiss/post is my other favourite...
Rob Stewart wrote:
From: "Jeff Flinn" <TriumphSprint2000@hotmail.com>
scope_guard g;
if (a) at_ease(g); ... if (b) attention(g); // emphasizing the appropriate syllables!
Interesting. "At ease" avoids the notion that "dismiss" raises of the guard no longer being around. It suggests that the guard isn't paying attention.
Unfortunately, I don't think "at_ease" reads all that well in the code. One usually doesn't tell code to "take it easy" or "chill" for a while, at least not in so many words. It just sounds strange to me.
So, if you choose to keep "dismiss," which really does seem like a nice choice, what is a good antonym? An interesting near antonym is "muster:"
scope_guard g; if (a) g.dismiss(); ... if (b) g.muster();
A variation on "guard" (the verb) is "protect," which has the right meaning and avoids overloading the word "guard" to excess:
scope_guard g; if (a) g.dismiss(); ... if (b) g.protect();
"Secure" is another choice.
I don't think we should concentrate on the human meaning of the word "guard". The scope guard object doesn't protect or secure anything, so the at_ease, attention, protect or secure do not reflect their semantic. Once again, these two functions are supposed to change the state of the object, nothing more. So their names should reflect this meaning.
Rob Stewart wrote:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
"Dismiss" would be the right word in English to tell the guard to go away and do nothing more.
Yes but what about its antipod - a function to enable the guard? Note that the guard may even be initially disabled (that's another reason I didn't like dismiss) and then it may be enabled in some place.
I see. I thought you somehow knew of "dismiss" in another language and didn't know the English word for it.
I think Markus is right: summon is the opposite of dismiss for a guard. The question is whether it reads well when used:
guard g; if (something) g.dismiss(); ... if (whatever) g.summon();
Well, as for me the "summon" name doesn't look very good. It looks like something should come from the "other side" :). The Brian's proposal ("guard") looks better but intersects with the class name itself. Maybe some other versions?
- The naming of the function make_guarded_call (in previous version it was make_transaction) is what I'm not sure of. This function in addition to a scope_guard creation calls some another functor. The semantic is grouping the "do" and "undo" actions in the user code. Does anyone have a better name?
How about "call_guarded" or "invoke_guarded?"
That might do. But doesn't the common make_ prefix mean that something (a guard in this case) should be created?
I took your question to mean that you were naming a function template that created a guard, called a function (object), and then destroyed the guard. Now it sounds as though you're creating a function object that does that and you want to name the function template that creates the function object. In that case, "make_guarded_caller" sounds about right.
I'm sorry if I made myself not clear enough. The function is supposed to do the following: - Take two function objects - Execute the first one immediately - Create a guard object that will call the second functor on destruction - Return the guard (user may bind it to a reference, which is typedefed to boost::scope_guard) So from the user's point of view the function executes the "do" action and returns a guard to perform "undo" action. This looks like some kind of transaction - the action shall be rolled back unless everything is ok and the result is committed (read: the guard is disarmed). The word "transaction" though is what I'd like to avoid. It is too wide spread an has to do with databases which is not the case.
Andrey Semashev wrote:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
What about "summon" as in "to summon a guard" and opposed to "to dismiss a guard". Markus
Markus Schöpflin wrote:
Andrey Semashev wrote:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
What about "summon" as in "to summon a guard" and opposed to "to dismiss a guard".
I think, the "summon" function would be too confusing for a user. Its purpose is not very clear from the name.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andrey Semashev wrote:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
How about "enable" and "disable"? Although I must admit that I never had the need to re-enable a scope guard, and that I favor "dismiss" for disabling.
Ariel Badichi <abadichi@bezeqint.net> writes:
Andrey Semashev wrote:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
How about "enable" and "disable"? Although I must admit that I never had the need to re-enable a scope guard, and that I favor "dismiss" for disabling.
Another thought: g = 0; it's easy to arrange that only a literal zero works there. I don't love it, but maybe it will get your ideas flowing. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Another thought:
g = 0;
it's easy to arrange that only a literal zero works there.
How?
I don't love it, but maybe it will get your ideas flowing.
Something like: g = guard::inactive; g = guard::active; or maybe g = guard::dismissed; g = !guard::dismissed; (ugh) ? Overloading operators here may be a bit counter-intuitive.
Ariel Badichi <abadichi@bezeqint.net> writes:
David Abrahams wrote:
Another thought:
g = 0;
it's easy to arrange that only a literal zero works there.
How?
Allow assignment only from a private member pointer type. It's similar to the operator safe_bool idiom.
I don't love it, but maybe it will get your ideas flowing.
Something like:
g = guard::inactive; g = guard::active;
or maybe
g = guard::dismissed; g = !guard::dismissed; (ugh)
?
No, the whole point of g = 0; was to get you out of having to find a name for this thing.
Overloading operators here may be a bit counter-intuitive.
Maybe so. I have no strong opinion on the matter. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
it's easy to arrange that only a literal zero works there.
How?
Allow assignment only from a private member pointer type. It's similar to the operator safe_bool idiom.
I thought you might mean that. That allows more than a literal zero, though (e.g., 5 * 5 - 25). By the way, that might work well for smart pointers; why don't shared_ptr and friends use this idiom?
No, the whole point of
g = 0;
was to get you out of having to find a name for this thing.
:)
Ariel Badichi <abadichi@bezeqint.net> writes:
David Abrahams wrote:
it's easy to arrange that only a literal zero works there.
How?
Allow assignment only from a private member pointer type. It's similar to the operator safe_bool idiom.
I thought you might mean that. That allows more than a literal zero, though (e.g., 5 * 5 - 25).
Yikes! I didn't know that. Too bad!
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? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Maybe because it allows more than a literal zero?
But then again, so does assignment (and implicit conversion) to any pointer? I'd like to have code like the following: boost::shared_ptr<int> foo() { return 0; /* instead of boost::shared_ptr<int>() */ } boost::shared_ptr<int> p(new int(42)); p = 0; // instead of p.reset()
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
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;
Rob Stewart wrote:
scope_guard g(my_undo_function); ... g.dismiss(); // or whatever name is selected ... g.protect(); // or whatever name is selected ...
Can someone please provide a motivating example for .protect? scope_guard vs scoped_guard aside for a moment. :-)
On 9/21/05 9:38 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
Ariel Badichi <abadichi@bezeqint.net> writes:
David Abrahams wrote:
it's easy to arrange that only a literal zero works there.
How?
Allow assignment only from a private member pointer type. It's similar to the operator safe_bool idiom.
I thought you might mean that. That allows more than a literal zero, though (e.g., 5 * 5 - 25).
Yikes! I didn't know that. Too bad!
Maybe it's not as "too bad" as you two think. You can use more than a literal zero for the conventional null-pointer too! Any integral expression that can be resolved at compile time that evaluates to zero can be used: void * x = 20 - 22 + 2; // works as NULL pointer! See section 4.10, paragraph 1 of the standard. (Also see s4.11-p1 and s5.19-p1.) So allowing this case is not any more surprising than the rules for built-in pointers.
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?
If that's the reason, maybe it could be re-evaluated. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
On Wed, 21 Sep 2005 18:21:23 -0400, David Abrahams <dave@boost-consulting.com> wrote:
- The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this.
How about "enable" and "disable"? Although I must admit that I never had the need to re-enable a scope guard, and that I favor "dismiss" for disabling.
Another thought:
g = 0;
it's easy to arrange that only a literal zero works there. I don't love it, but maybe it will get your ideas flowing.
This is confusing to me. This makes it appear that the guard is disabled for good, and can never be re-enabled. Same with "reset". I like "dismiss" for disabling, but I don't think "summon", "guard", or "post" intuitively make sense. "enable"/"disable" or "activate"/"deactivate" sound better to my ears, unless there is a better word to pair with "dismiss". To be honest, I'm not convinced that too much focus on comparing this concept with a real-world guard is a good thing. -- Be seeing you.
"Thore Karlsen" <sid@6581.com> wrote
[cut] ...To be honest, I'm not convinced that too much focus on comparing this concept with a real-world guard is a good thing.
hmm... if its not conceptually a guard... then why call it one? How about : guard.up(); guard.down(); regards Andy Little
On Thu, 22 Sep 2005 16:23:16 +0100, "Andy Little" <andy@servocomm.freeserve.co.uk> wrote:
...To be honest, I'm not convinced that
too much focus on comparing this concept with a real-world guard is a good thing.
hmm... if its not conceptually a guard... then why call it one?
Indeed. Maybe there's a better name for it, I don't know. I don't mind the name, just the implications of taking the name too literally.
How about :
guard.up(); guard.down();
I'd prefer more descriptive verbs. -- Be seeing you.
From: "Andy Little" <andy@servocomm.freeserve.co.uk>
"Thore Karlsen" <sid@6581.com> wrote
How about :
guard.up(); guard.down();
... xyz.up(); ... xyz.down(); Out of context, and without a variable including (if not ending with) "guard," "up" and "down" don't fit well. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"Rob Stewart" <stewart@sig.com> wrote in message news:200509221909.j8MJ9RKg013387@shannonhoon.balstatdev.susq.com...
From: "Andy Little" <andy@servocomm.freeserve.co.uk>
"Thore Karlsen" <sid@6581.com> wrote
How about :
guard.up(); guard.down();
... xyz.up(); ... xyz.down();
Out of context, and without a variable including (if not ending with) "guard," "up" and "down" don't fit well.
Is this not this variable always going to be called guard?(For example see ScopeGuardTest.cpp in the distro) I assume theres only ever one per scope Whatever I guess that these wont work either for the same reason. xyz.on(); xyz.off(); regards Andy Little
On Thu, 22 Sep 2005 20:54:22 +0100, "Andy Little" <andy@servocomm.freeserve.co.uk> wrote:
How about :
guard.up(); guard.down();
... xyz.up(); ... xyz.down();
Out of context, and without a variable including (if not ending with) "guard," "up" and "down" don't fit well.
Is this not this variable always going to be called guard?(For example see ScopeGuardTest.cpp in the distro) I assume theres only ever one per scope
No, I routinely have more than one guard per scope. -- Be seeing you.
From: Thore Karlsen <sid@6581.com>
I like "dismiss" for disabling, but I don't think "summon", "guard", or "post" intuitively make sense. "enable"/"disable" or
I think "guard" does make sense, but it overloads the other uses of the word in the library which will make verbal discussions harder.
"activate"/"deactivate" sound better to my ears, unless there is a better word to pair with "dismiss". To be honest, I'm not convinced that too much focus on comparing this concept with a real-world guard is a good thing.
I think the object is aptly named and trying to find a suitable pair of words that map to real world concepts is worthwhile. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (1)
-
Andrey Semashev -
Andy Little -
Ariel Badichi -
Brian Ravnsgaard Riis -
Daryle Walker -
David Abrahams -
Jason Stewart -
Jeff Flinn -
Markus Schöpflin -
Peter Dimov -
Rob Stewart -
Thore Karlsen -
Yuval Ronen