By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,745 Members | 1,957 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,745 IT Pros & Developers. It's quick & easy.

basic

P: 37
so what i am trying to do is write a program for a robotics project (think remote control using keyboard as input). To start I am writing this thing as a C++ console app.

Now I have taken a coarse on OOP so I have a decent knowledge of the syntax however my understanding of structure is very lacking (I would personnally blame the coarse for being a memorization session but blame wont get my anywere). while I could do this in C I mostly want to do this in C++ for education purposes.

Now, as far as the program goes I could and have in the past done this same thing very easily in C quite easily by simply have the program:
1) Collect user input
2) Perform the appropriate action,
3) waste some time with nested for loops or transmit signal, receive confirmation signal, stop transmitting.
4) and then check for user inputs again

with all of this in a while(1) things are somewhat easy.
however it would have inherent flaw that the program is tied up while waiting! (could this be solved via use of interrupts perhaps?)

would this be written as a lengthly driver with one class and one object, were the driver simply calls a bunch of functions:
right now it occured to me that i should make input the object and give it characteristics (like isActive, currentState, timeCollected etc)

is my interpretation that the input should be the object and there should be one class correct?

much thanks in advance
Jan 17 '09 #1
Share this Question
Share on Google+
7 Replies


P: 37
My honest apologies regarding the title, that was a little bit of an "oops." and now I can't seem to find an edit button so I assume posts are uneditable.

Edit (oh the irony): Initial posts are uneditable >.>
Jan 18 '09 #2

weaknessforcats
Expert Mod 5K+
P: 9,197

P: 37
I hadn't even known one could change the focus of the switch in this way. Pretty neat, maybe the state machine stuff they taught me in school is in some way useful ;)

question though:
I was going through the c implementation you added (to make sure it made sense to me before I got to OO)
I was confused by "state = 0" since there is no case 0: or default:
Also I had to remove break; since it was breaking from the entire switch and not checking the value of state.

That been said the concept is the most important thing!

Also if anyone reading this knows a good site (or perhaps fabulous book if(bookAwesomeness > siteAwesomeness) that doesn't bother itself with syntax and just goes over oop and how it should be implemented structure wise that would be invaluable!

Thanks!
Jan 18 '09 #4

P: 37
so I have been going over this some more because I am very much beginning to see how advantageous this [using a state machine] can be, especially if I can have the switch move between output states and read in states quickly, updating the list of outputs making my program better handle simultaneous inputs.

That being said I am having a problem. I sort of got to it above and thought it was a simple case of to break or not to break...

for:
Expand|Select|Wrap|Line Numbers
  1. switch(state){
  2. ...
  3. default:
  4. break;
  5. }
if I use break in my 1st case, it exits the switch entirely
if I don't use break, the switch does not check the value of state when it decides what to do next it just moves down my list until it gets to default:

what am I doing wrong? I looked via google, some people are doing this way and don't seem to have my problem, some are using GOTO... which I understand is a baaaaad idea and some are even putting it in a while loop (which actually makes some sense to me, but I want to understand why this isn't working without the while for me!)

Thanks!
Jan 19 '09 #5

Expert 10K+
P: 11,448
Would something like the following solve your problem?

Expand|Select|Wrap|Line Numbers
  1. for (int state= STARTSTATE; state != ENDSTATE; ) {
  2.    switch (state) { // yout state machine
  3.       // don't fall through the cases but switch the state value instead
  4.    }
  5. }
  6.  
kind regards,

Jos
Jan 19 '09 #6

weaknessforcats
Expert Mod 5K+
P: 9,197
Yes, heed JosAH. The state machine requires that each state know the successor state. That said you must return to the switch (using C) using a loop.

Personally, I would use while(1). That is, an infinite loop. The switch would have a case for the exit state and there I would return from the function.

You enter the loop with the initial state already set.

But what JosAH says works as well up until processing is involved with either the initial or exit state. Then you need actual cases for these states.
Jan 19 '09 #7

P: 37
great to know ;) I just saw some people had written state machines without so I didnt want to learn to apply an unnecessary step.

Thanks everyone for the help, and any tips on learning optimal structure for OOP are of coarse appreciated.

Cheers
Jan 20 '09 #8

Post your reply

Sign in to post your reply or Sign up for a free account.