jUST LEARNING FUNCTIONS
I am just learning functions. I understand that the code
is a function that takes no input and returns nothing to the caller, but if I have:
void MegaMillion (void)
where I'm trying to get rid of all the gotos, how do I write all the goto replacement functions? What do I place inside the ()? What do I do with the label "Start?" What belongs in the () of the exit code?
int main ()
cout << "For Florida MegaMillion press #1" << endl << endl;
cout << "For Florida Lotto press #2" << endl << endl;
cout << "For National Power-Ball press #3" << endl << endl;
cout << "To start over press #4" << endl << endl;
cin >> z;
if (z == 1)
cout << "You have chosen to play Florida's MegaMillion Lotto," << endl << endl;
if (z == 2)
cout << "You have chosen to play the Florida Lotto." << endl << endl;
if (z == 3)
cout << "You have chosen to play the National Power-Ball Lotto," << endl << endl;
if (z == 4) goto Start;
if (z != 1 && z != 2 && z != 3 && z != 4)
cout << "You have chosen to end the program." << endl << endl;
. . . . therry
If the functions take no parameters, then you put nothing in the ().
You replace Start and goto Start with a loop (perhaps a do while loop).
If you do it properly, you won't need the exit call at all.
What book/website are you learning from? They shouldn't have told you to use goto's. They should have taught you about loops and functions. Get a better book/website.
The best way is to not put the goto in there to begin with.
An easy way to do that is when starting out with writing the program, put the loop in first, and then gradually add the stuff inside it.
In other words, more top-down thinking, less bottom-up thinking.
In this case a do .. while loop is the most appropriate, and you want the loop condition to be while z == 4
you have declared your control variable z as a char, but then you test for number values.
change it to an int, or it could be unsigned for a very clear indication that z is never intended to hold a -value.
Also consider renaming it, single letter variables are ok for some things, there are accepted i,j,k for example that is a common convention for nested loops. But in the context of your program ' z ' does not really say anything. Better to write ' choice ' or 'gameChoice' or ' draw ' maybe.
On another note I find it interesting seeing people use the ' exit ' call in recent threads, is this some kind of hangover from another language? I appreciate it is probably a standard keyword but i only ever use it in shell stuff, and have never considered it in my own C or C++, stuff, I assume it breaks the whole program execution, even from within a called function.. If so then I would advise the OP uses return or break calls in the loop if such a thing be neccesary.
By the way... my very first post on the cboard was also a lottery game question... was nice to see this one.. good luck!
What is wrong with exit ?
Originally Posted by rogster001
I thought it was a fabulous way of ending a program (process, more accurately, afaik) without getting a flaggy mess when required !
(The only time when it can mess up, I think, is when used with system calls like clone(), or some of the exec functions )
How would that make sense? A process is a process, and exit is exit, regardless of the language. Which is to say, your criticism does not have any added meaning in C/C++. Perhaps the reason you see it more appropriate to shell stuff is because the shell stuff you do is smaller in scale?
Originally Posted by rogster001
Returning an error or throwing an exception should be preferred where applicable, but that is not really an issue specific to using exit() -- it's just a principle that, eg, a library function should not just end a process for whatever reason. In situations where it is appropriate to end the process (because it cannot continue, or it would not make sense if it did), I agree with manasij: unless there is some particular reason not to use exit, that's what exit is for (even if you wrap it together with whatever else).
That's just as true in shell programming as in C/C++, I think.
The shell stuff is pretty much smaller scale yes, but I meant that perhaps the op was using exit and would get a surprise when the whole program ends, instead of just returning from the function, unless thats what happens with exit in c languages, like i say i have never written that line. I was not criticising either.
exit() does not allow objects to be properly destroyed. it simply ends execution right away. a good example of why this is bad is if your program creates files for temporary use (not necessarily the same thing as temporary files), and is supposed to remove them upon destruction of certain objects, those files will never be removed if you call exit(), and will eat up disk space over time. atexit() was created to handle situations like this, but I think that it would be incredibly bad practice to start sprinkling atexit() calls all over your code, especially as the scale of the project starts to get larger. in my programs, I have a specific type of exception (that isn't derived from std::exception), and that exception type only gets caught in main(). I don't ever use catch (...), except below the one catch (TerminateProgramException) because it doesn't give any meaningful information. it only tells you that something was thrown. there is no way to find out what it was (afaik). this ensures that when I want to end my program in a way consistent with RAII, I throw an instance of TerminateProgramException, which gets caught in main, which simply returns, and things get destroyed as they are supposed to.
Can't something be done at a lower level ? By coupling signal handlers with the destructor(of a resource manager..say) instead of atexit ?
Originally Posted by Elkvis
//My understanding of it is superficial, at best... so apologies if the above statement lacks substance,
in theory, you could do that, but exit() is generally an operating system call. it simply instructs the system to terminate the current process. what you suggest would still necessarily require at least one call to atexit().