Thread: jUST LEARNING FUNCTIONS

I am just learning functions. I understand that the code

Code:

void MegaMillion (void)

is a function that takes no input and returns nothing to the caller, but if I have:

Code:

int main ()
{
    Start:
    char z;
        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;
MegaMillion();
    }

 else
 if (z == 2)
     {
       cout << "You have chosen to play the Florida Lotto." << endl << endl;
FloridaLotto();
    }

 else
 if (z == 3)
    {
       cout << "You have chosen to play the National Power-Ball Lotto," << endl << endl;
        PowerBall();
    }
 else
 if (z == 4) goto Start;
 else
 if (z != 1 && z != 2 && z != 3 && z != 4)
    {
        cout << "You have chosen to end the program." << endl <<    endl;
        exit();
    } 
     return 0;
}

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?
. . . . therry

Originally Posted by rogster001

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.

What is wrong with exit ?
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 )

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.

Originally Posted by Elkvis

exit() does not allow objects to be properly destroyed.

Can't something be done at a lower level ? By coupling signal handlers with the destructor(of a resource manager..say) instead of atexit ?
//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().