#1
  1. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2003
    Posts
    13
    Rep Power
    0

    Question How to exit without exit?


    Home work agian.

    I'm required to write a sales analysis program.

    One of the function dose enter a new salesperson, it will prompt for personal detail. but if user keys in -1 at any point, it will cancel process and return to main menu options.

    BUT according the programming standards of this, " GOTO statement, BREAK keyword and EXIT function are NOT allowed in any program. In C++ the use of Return to jump out of a function premeaturely is not Structured and therefore not allowed".

    What can I do ?Thanks!!
    :confused: :confused: :confused:
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    54
    Rep Power
    12
    You could throw an exception if the user enters -1 and then catch that exception in your main() function.
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2003
    Posts
    68
    Rep Power
    12
    >In C++ the use of Return to jump out of a function premeaturely is not Structured and therefore not allowed".
    LOL! Not allowed, huh? Whoever wrote that obviously works in a clearnroom type ultracontrolled environment. In the "real" world, we do what works. Your restriction is ridiculous. To meet it exactly, you would have to maintain multiple processes or threads and constantly poll for the desired cancellation input or test for -1 at every call for input, both of these are unacceptable for something this simple. As you can probably see, using one of those "not structured" evil keywords would simplify everything about the program *and* make it faster as well as easier to understand. Loosen up the restriction of watching for -1 at all times and you can do something like this without using exit, goto, break, or a nested return:
    Code:
    while (getline(salesperson, cin) && salesperson != "-1") {
      // Enter the details
    }
  6. #4
  7. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,184
    Rep Power
    2222
    Your instructor is trying to teach you guys structured programming, which is a good thing in general, but which can cause problems when used dogmatically.

    One rule is that there be no global variables; everything the function needs to know must be passed in through the argument list and any working variables must be local. Shortly after I started working professionally, we had an embedded program with a 8086 target (hey, it was the latest thing at the time). So I applied the structured programming rules and declared a large array I needed as local. Blew the stack clean off the board! That is when I learned that there are times when you do need to declare and use global variables.

    Similarly, you are up against the rule that every subprogram must have one-and-only-one entry point and one-and-only-one exit point. That is generally a good idea, especially regarding one-and-only-one entry point, but enforcing the one-and-only-one exit-point rule can lead to some really gnarly and convoluted structures that have your code marching off the right side of the screen and that can be very difficult to understand or to modify. Remember, a couple of the key reasons for using structured programming is readability and maintainability, so dogmatically following this one-and-only-one exit-point rule can defeat the purpose of using structured programming in the first place.

    On my first job (which was assembly programming) I was shown another programmer's flowcharts. They had all been mandated to use structured programming, but in this one routine it just didn't make any sense. But he HAD to use structured programming, so he declared a flag variable call the "structured flag" and he set it upon entering this routine and reset it on the way out. It didn't do anything, but at least it flagged the routine as being structured.

    So in some cases of having to strictly maintain the structure, set a flag on an error condition and execute the rest of the function only if the flag is not set. Though froggy's suggestion of throwing an exception is better.

    To borrow from a recent movie, most rules should be looked upon as being guidelines. And artistry is knowing when and how far to bend or even break the rules.
  8. #5
  9. Contributing User

    Join Date
    Aug 2003
    Location
    UK
    Posts
    5,114
    Rep Power
    1803
    Code:
    do
    {
        <get input> ;
        if( <input is valid> )
        {
            <process input> ;
        }
    } while< input is valid> ;
    Replace the <xxx> with appropriate code. Note that the validity of input is tested for validity twice. When the if(...) fails, the while(...) will fail also. Some dislike the do...while construct, so an alternative is as follows:
    Code:
    <get input>
    while( <input is valid> )
    {
        <process input> ;
        <get input>
    }
    This is less complex, and the condition is tested at one point only, however the input accurs in two places. Take your choice.

    To avoid goto, break, and continue is easy, in over 15 years as a professional software engineer, I have never had to resort to either outside of breaks in case constructs. Sometimes you need to test conditions more than once. If the condition is complex, and/or will have to be tested often, then evaluate the condition once and assign the result to a boolean, and test the boolean:
    Code:
    bool exit = <boolean expression> ;
    
    if( !<exit> )
    {
        <do stuff>
    }
    This technique can also be used to avoid excessive nesting of ifs.

    Clifford
  10. #6
  11. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    95
    Originally posted by dwise1_aol

    To borrow from a recent movie, most rules should be looked upon as being guidelines. And artistry is knowing when and how far to bend or even break the rules.
    lmao "ahoy matey!". at least i think that's the movie you're talking about. all that you said makes a lot of sense, i wish my teacher's had explained it that well. i was taught in the same Nazi'ish manner the person who started this thread must have been. any use of globals or a goto was unacceptable. back then i didnt understand why, but even now that i do i still think my teacher was a little overboard. everything in the language is there for a reason , so making blanket "DONT USE THAT" statements doesnt really make sense. it had to be put there for a reason...although i still dont understand the purpose the gets() function and why it was ever implemented and still continues to be :D
  12. #7
  13. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,184
    Rep Power
    2222
    Originally posted by infamous41md
    lmao "ahoy matey!". at least i think that's the movie you're talking about. all that you said makes a lot of sense, i wish my teacher's had explained it that well. i was taught in the same Nazi'ish manner the person who started this thread must have been. any use of globals or a goto was unacceptable. back then i didnt understand why, but even now that i do i still think my teacher was a little overboard. everything in the language is there for a reason , so making blanket "DONT USE THAT" statements doesnt really make sense. it had to be put there for a reason...although i still dont understand the purpose the gets() function and why it was ever implemented and still continues to be :D
    I think you're thinking of the right movie. Though the remark about artistry knowing when to bend or break the rules is my own observation (though I will not discount my not remembering having heard or read it years ago). I thought of it again just a couple days ago when I started my first "advanced" Lindy class and the instructor started off teaching a cool swingout that broke all the rules he had taught us in beginning class.

    Which may well be a good justification for stricter rules in the beginning. Perl's motto is "there's more than one way" and it doesn't just apply to Perl. Think of all the ways to run a program or to copy and paste something or copy a file within Windows Explorer. We know all those ways because we're no longer (quite the) beginners (we used to be). We can keep track of what's going on. Try teaching a beginner to do the same things. If you let them know all their options, their brains will start to melt. But if you just teach them one way to get the job done, then they can handle it. After they've mastered that way, then start showing them the alternatives.

    So in a beginning programming class, especially if there are complete beginners in it, you do need to take them almost lock-step through relatively strict procedures for them to get the basic job done. And once they're comfortable with that, then show them the other ways to do it.

    And you also need to teach them good programming habits -- and those rules really are good guidelines to follow. But, kind of like with morality, if you not only need to be taught the rules but also why that rule exists and how it will help you and what problems it protects you from and how it protects you. But again you cannot impart all that understand (nor even any of it -- the student must gain the understanding himself; all the teacher can do is try to guide him there), so first must come the rules and then as the students gain some experience you can work on the understanding.

    There's a lot more to teaching than most people think.
  14. #8
  15. Contributing User

    Join Date
    Aug 2003
    Location
    UK
    Posts
    5,114
    Rep Power
    1803
    goodwillV, your teacher is right, all those things he has prohibited are unnecessary and can lead to error prone unmaintainable code. Many books provide circumstances where thier use may be justified but there are invaribly other methods, with little extra effort. The length of time others have spent waxing lyrical about thier hacky coding practices and dodgy movies;), they could have spent writing better code. (waits for flame...). In the end, if you remain an amatur coder, doing it for your own amusement, then fine; but if you expect ever to code professionally, and especially in a team environment, then you'd be wise to heed the voices of experience.

    From a more pragmatic point-of-view, ignoring your teacher, because some dude on a geek forum told you it was OK is not going to get you far (grade-wise)!

    What does worry me is that your teacher does not seem to have conveyed enough knowledge for you to solve this problem, or to understand the reasons for the 'restrictions'. (Or you slept in class!:)

    Clifford
  16. #9
  17. No Profile Picture
    status unknown
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2003
    Posts
    262
    Rep Power
    12
    > BUT according the programming standards of this, " GOTO
    > statement, BREAK keyword and EXIT function are NOT allowed
    > in any program. In C++ the use of Return to jump out of a
    > function premeaturely is not Structured and therefore not
    > allowed".
    First of all, the use of return (note - all lower case) is allowed in C++. It's a perfectly valid statement to use. So strictly speaking what you should have said is "In my class the use of return ...".

    Secondly, placing unnecessary constraints in the parts of the language that someone can use in an assignment is one thing, but don't be fooled into thinking that such constraints exist generally.

    As an example, there is an ongoing debate about the use of goto in structured languages that has been going on for several decades. Some languages exclude it deliberately, others - designed to support good software engineering practice - still support it.

    At the moment you belong to an institution that is imposing its own values on you. Fair enough. One day you'll be out of there. Then you need to develop and apply some common sense of your own.

    Regardless of the construct, you need to understand how it us used. You need to understand when it can be used. You need to understand when it shouldn't be used. And why. And then - if you have the freedom to do so - you make an educated choice based on the knowledge you have.

    You don't always have freedom of choice, for instance you may be working for a company that has a coding standard that forbids the use of goto at all, even though there are some elegant uses of it that some consider appropriate. Don't worry about it. Follow the coding standard. Challenge it through the appropriate channels if you disagree with it, but follow it. It brings advantages.

    Just remember, one day, generally it will be up to you to decide what to use when, and as long as you understand when and why something is good or bad, then you can make a decision accordingly. Anyone who simply says "don't use this" without qualifying it is well meaning but, ultimately, misguided.

    I would suggest that there is a small number of circumstances where goto is perhaps better than the alternatives but in general should be avoided. And break is a perfectly valid keyword in many circumstances. In C++ the use of exit() is considered poor but as a novice it's easier to use and understand than the alternative.

    Not all C++ programmes apply strict 'structured programming' in the way that you're currently being taught.

IMN logo majestic logo threadwatch logo seochat tools logo