I'm trying to make a program in which the user must enter a number and if the user enters a letter by accident the program gets screwed up. I'm trying to use the isdigit function to make sure that its a number and that fragment of my program looks like this
Whenever i try to use the program and enter a letter my program still gets screwed up but if i take the not out and enter a number it works fine. Oh and a is a double if that plays any part.
isdigit checks single digits only, not whole numbers. If the user inputs a digit, it stores it in the double. If the user inputs something that can't be stored in a double, like a letter, cin fails silently and you have to cin.clear and cin.ignore('\n', some large number) [or maybe it's some large #, \n] so that you clear the failure and then ignore the invalid input.
You can check for failure using if (!cin).
Edit: Sorry for the brief reply, sort of tired. Hopefully that's enough to get you going with google or forum search.
I realized the moment I fell into the fissure that the book would not be destroyed as I had planned.
double decimalnum;
bool gotValidInput = false;
while (!gotValidInput) { //loop until we get some valid input
cout << "enter a #: ";
cin >> decimalnum; //if a non-number (this includes decimal #s since we're using a double) is entered, cin will go to a fail state
//in other words if the input we got doesn't match the variable type, cin goes into a fail state.
//so if we had an int type and a double was entered, it would fail. i think. or maybe it would truncate the decimal off. i dunno
if (!cin) { //cin has entered a fail state. when cin is in a fail state all cin statements will get skipped
cout << "that's not a number" << endl; //tell the user they suck
cin.clear(); //get rid of the fail state flag
cin.ignore(900, '\n'); // 900 is the # of invalid characters to ignore, i just picked some number out of the air
} else {
gotValidInput = true; //cin's not in a fail state, so we must have gotten valid input
}
}
Last edited by MarauderIIC on Sat Mar 07, 2009 3:13 pm, edited 1 time in total.
Reason:switched clear/ignore cause it didnt work the other way
I realized the moment I fell into the fissure that the book would not be destroyed as I had planned.
Frosty wrote:a Goto statement should Never be used
see this is what angers me. you learnt that from one of your subpar professors or some shitty online text.
i agree that goto should not be used to get out of a programatical error, by gotos are perfectly fine to use.
if you program in assembly you use them all the time.
GOTO's are fine, there is nothing wrong with them, the problem is when shitty programers use them, thats when shit happens.
Some person, "I have a black belt in karate"
Dad, "Yea well I have a fan belt in street fighting"
Frosty wrote:a Goto statement should Never be used
see this is what angers me. you learnt that from one of your subpar professors or some shitty online text.
i agree that goto should not be used to get out of a programatical error, by gotos are perfectly fine to use.
if you program in assembly you use them all the time.
Agreed that goto statements is fine when used in good context
But unless you're extremely keen., you'll misuse it and that will lead to some nasty bugs
and breaks in the flow of your program.
Frosty wrote:a Goto statement should Never be used
see this is what angers me. you learnt that from one of your subpar professors or some shitty online text.
i agree that goto should not be used to get out of a programatical error, by gotos are perfectly fine to use.
if you program in assembly you use them all the time.
GOTO's are fine, there is nothing wrong with them, the problem is when shitty programers use them, thats when shit happens.
Damn straight!
I use the goto. In fact that was what I used before I figured out the syntax of VB for statements. My teacher said "you shouldn't really use goto..." well it worked.
I should mention that this was after I had blocked out my previous experience with VB.
Gyro Sheen wrote:you pour their inventory onto my life
IRC wrote:
<sparda> The routine had a stack overflow, sorry.
<sparda> Apparently the stack was full of shit.
the main reason that gotos are "banned" is not because of bugs, although thaey can cause some ugly ones.
gotos are banned because of a much more sinister and lazy reason, gotos lead to spaghetti code,
and if the original coder gets fired, quits or dies, the other coders are left trying to fix something they really cant because they dont know why tyhe program works like it does.
and inevetably have to recode the entire program.
note, proper use of gotos can significantly decrease the size of a program.
Some person, "I have a black belt in karate"
Dad, "Yea well I have a fan belt in street fighting"
And now about the code. I typed everything almost the as I was told but when i type in a letter my program enters the "I dont know what to do" state and just repeats the cout commands in the while loop heres my code
Gotos are one of the cleanest ways to exit nested loops. Why did we even start talking about gotos?
Hmm herby, this is what happens when I program straight into the forum. Try swapping the order of ignore and clear, that's the way I'm seeing it from google hits.
for (int i = 0;i < something;++i) {
cout << "initial processing start" << endl;
if (errorInitial) { display only this error; get out of all loops; }
for (int j = 0; j < something;++j) {
cout << "mid processing start" << endl;
if (errorMid1) { display only this error message; get out of all loops; }
for (int k = 0;k < something;++k) {
cout << "mid processing 2 start" << endl;
if (errorMid2) { display only this error message; get out of all loops; }
}
cout << "mid processing 3 start" << endl;
if (errorMid3) { display only this error message; get out of all loops; }
}
cout << "post processing start" << endl;
if (errorPost) { display only this error; get out of all loops; }
}
You could use break, but you'd have to check for every single relevant error flag before every single processing is done -- added to the ifs that are already there -- since break; will only break its local loop, OR you could put
}//end of outermost loop
nestedParser_escape:
//go on to next task
So in general, yes, don't use a goto. But it does have its specific uses. Don't use a goto if there's something else that can do the job as well or better (better includes clarity). "Never" is never true in programming. Ha that's a neat unintentional pun.
Last edited by MarauderIIC on Fri Feb 27, 2009 1:57 pm, edited 3 times in total.
Reason:"clarity", like usual
I realized the moment I fell into the fissure that the book would not be destroyed as I had planned.