Click here to Skip to main content
15,881,852 members
Articles / Programming Languages / C++11
Tip/Trick

Removing Ugly Flags in C++

Rate me:
Please Sign up or sign in to vote.
4.00/5 (13 votes)
18 Oct 2011CPOL 63K   6   29
Using the Call Gate idiom to reduce number of boolean flags and state variables.
Let's consider a typical use case.

C++
struct car
{
  car()
    :started_(false)
  {
  }
  ~car()
  {
    stop();
  }

  void start()
  {
    if(started_)
       return;
    do_start();
    started_=true;
  }
  void stop()
  {
    if(!started_)
       return;
    do_stop();
    started_=false;
  }
private:
  bool started_;

  // do actual work
  void do_start();
  void do_stop();
};

Doesn't the 'started_' flag look ugly? It does to me. With the Call Gate idiom, that could be changed to:

C++
struct car
{
  car()
    :start_( boost::bind(&car::do_play, get_this()) )
    ,stop_( boost::bind(&car::do_stop, get_this()) )
  {
    //wire the gates
    start_.wire_on(stop_); //'start' opens the 'stop' gate
    stop_.wire_on(start_); //'stop' opens the 'start' gate
  }
  ~car()
  {
    stop();
  }

  void start()
  {
    start_();
  }
  void stop()
  {
    stop_();
  }

private:
  gate start_;
  gate stop_;

  car* get_this() { return this; }

  // do actual work
  void do_start();
  void do_stop();
};


Replacing only one bool with call gates is probably an overkill, but there is a more interesting sample in Call Gate Idiom, and an actual implementation of the call gates.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
United States United States
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
GeneralReason for my vote of 2 What looks ugly to me in the first p... Pin
nv314-Dec-11 4:16
nv314-Dec-11 4:16 
GeneralMy vote of 5: It is a nice way to hide the annoying state ca... Pin
semmel7125-Oct-11 2:06
semmel7125-Oct-11 2:06 
GeneralReason for my vote of 5 Nice! It centralizes the setup of th... Pin
semmel7125-Oct-11 2:02
semmel7125-Oct-11 2:02 
GeneralReason for my vote of 1 Why make it simple when you can make... Pin
YvesDaoust24-Oct-11 23:01
YvesDaoust24-Oct-11 23:01 
GeneralReason for my vote of 3 Replacing ugly Code with bloated ugl... Pin
Johann Anhofer24-Oct-11 10:01
Johann Anhofer24-Oct-11 10:01 
GeneralReason for my vote of 1 The article is way too short to expl... Pin
Wolfgang_Baron18-Oct-11 13:18
professionalWolfgang_Baron18-Oct-11 13:18 
GeneralFor a more complex example, please see the player type at th... Pin
egladysh18-Oct-11 7:06
egladysh18-Oct-11 7:06 
GeneralReason for my vote of 2 No practical application comes easil... Pin
xelous218-Oct-11 3:29
xelous218-Oct-11 3:29 
GeneralReason for my vote of 4 Interesting subject, would love to s... Pin
Julien Villers17-Oct-11 22:32
professionalJulien Villers17-Oct-11 22:32 
GeneralReason for my vote of 4 An interesting idiom. Pin
Jon Summers17-Oct-11 9:33
Jon Summers17-Oct-11 9:33 
QuestionWhy replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
Stefan_Lang18-Oct-11 3:54
Stefan_Lang18-Oct-11 3:54 
AnswerRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
egladysh18-Oct-11 7:40
egladysh18-Oct-11 7:40 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
Stefan_Lang18-Oct-11 23:26
Stefan_Lang18-Oct-11 23:26 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
xelous219-Oct-11 0:12
xelous219-Oct-11 0:12 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
egladysh19-Oct-11 7:54
egladysh19-Oct-11 7:54 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
Stefan_Lang19-Oct-11 22:49
Stefan_Lang19-Oct-11 22:49 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
egladysh20-Oct-11 6:50
egladysh20-Oct-11 6:50 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
Stefan_Lang21-Oct-11 0:40
Stefan_Lang21-Oct-11 0:40 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
egladysh21-Oct-11 6:38
egladysh21-Oct-11 6:38 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
Stefan_Lang25-Oct-11 4:59
Stefan_Lang25-Oct-11 4:59 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
egladysh25-Oct-11 5:41
egladysh25-Oct-11 5:41 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
Stefan_Lang25-Oct-11 5:58
Stefan_Lang25-Oct-11 5:58 
GeneralRe: Why replace an ugly flag with two more ugly objects at the cost of functionality and maintainability? Pin
egladysh25-Oct-11 7:01
egladysh25-Oct-11 7:01 
GeneralFeedback Mechanism Absent Pin
xelous218-Oct-11 3:26
xelous218-Oct-11 3:26 
An interesting idea, and its nice to see the boost::bind function being put to good use, however, there seems to be a rather obvious strength to the boolean flags when compared to your approach, that is the individual flags can indicate the state the object is in, whether your "knob" is turned on or off, whether your bool is true of false, an external observer can not tell.

You do make mention of resetting all your "off wires" and your "on wires" within your offsite example, indeed you state:

"To enforce the constraints, the player would have to keep the current state so that the play(), pause(), resume(), stop() methods could enable/disable the corresponding knobs based on the state. Keeping and checking the current state isn’t much different from the playing_ flag used in the first sample."

This is assuming your states are mutually exclusive, when they may not be, you may have to exit one condition, before starting the next.

But all that aside, your article really aims itself at "Reducing the ugliness of boolean flags", I'm sorry to say I find the "Knob" class to be far more cumbersome than a boolean could ever be. True the latter is not as flexible, but why try to fix something that's not broken?

My friend, I think your idea is good, but lacking that "killer application", neither the example you give here, nor the one from your external site smacks of a good reason to abandon boolean's or enumerations for status flagging.

Indeed, after implementing all your Knobs, Wires and function binding callbacks, I'd say a good old integer and binary mask shows itself to be infinitely neater, easily maintained and by far simpler to document.
GeneralRe: Feedback Mechanism Absent Pin
egladysh18-Oct-11 7:50
egladysh18-Oct-11 7:50 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.