From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-22 09:07:40
From: Brian Ravnsgaard Riis <brian_at_[hidden]>
> 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
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:
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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk