Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Help with C

  1. Apr 20, 2009 #1
    Hello, I am learning to program in C. I have to do a program for a simple calculator. It should have to menus, one the operation menu with the addition, subtraction, multiplication and division, the second one with the options new calculation, other operation and finish. I have done, there is not problem when I compile, but when I execute then doesn't appear the second menu. I don't find where is the mistake. Could someone help me?

  2. jcsd
  3. Apr 20, 2009 #2
    "goto" is a bad idea. Rewrite it with while/for/do loops and functions instead.
  4. Apr 20, 2009 #3
    I have done with goto, because I don't know how can I do with other loop.
  5. Apr 20, 2009 #4
    The blocks following begin: and oper: could be moved into functions. You could then put the "second menu" into a loop, and call the functions within the loop instead of saying goto.

    It looks to me like the reason the "second menu" does not appear is that while (op<=4); means it is impossible to leave your "first menu" unless you choose menu option 5 (not a listed option).
  6. Apr 20, 2009 #5
    I have found the problem, it was that I have put while(op<=4) at the end of the first menu instead of at the end of the second menu. When I put it at the end of the second menu, it works.

    My next step is to try to change the goto loop for one of the other you purpose.
  7. Apr 20, 2009 #6


    User Avatar
    Homework Helper

    I don't understand why most programmers are "anti-goto". ... moved to "goto" thread.
    Last edited: Apr 20, 2009
  8. Apr 20, 2009 #7
    The main problem with goto is that it can do almost anything. When reading code, it's harder to figure out what a goto or label is for than what a loop is for, because the goto could do so many things (jumping control to anywhere in the program). A loop can only apply to the loop body, and two loops can't "overlap" the way gotos can. That means it is easier to reason about loops than gotos, so loops are preferable when possible.
  9. Apr 20, 2009 #8
    "I don't understand why most programmers are "anti-goto"."
    For high-level programming, they are generally considered too unstructured. They support ad-hoc programming and decrease readability.

    "It's far easier to search for a label than a trailing right brace."
    I disagree. With proper use of white space, C-style brace notation makes it very easy to see the block-structure.

    "Regardless of how you write your C code, eventually the assembly equivalent of a "goto", a branch or jump instruction is going to be used (except machines that have conditional execution of instructions such as the Motorola 68000 series, and it only helps with 2 to 4 instruction sequences)."
    What do you mean here? Yes, whenever code is translated into assembly language, loops and conditionals become the equivalent of "goto".
    But any and all programs require only a single while loop and the if-then-else structure. This is provably true.

    "If there are multiple entry or exit points in a program's loops, then goto's are OK."
    I respectfully disagree. If your code starts using several goto's, you probably need to rework your design.
  10. Apr 20, 2009 #9


    User Avatar
    Homework Helper

    moved to the "goto" thread.
    Last edited: Apr 20, 2009
  11. Apr 20, 2009 #10
    "Just like anything else, goto's can be used appropriately or inappropriately. Inappropriate use doesn't invalidate using goto's."
    Fair enough. I like to avoid them, however, because I feel it's all too easy to misuse them. I guess when it comes to the GOTO I prefer to err on the side of not using them.

    "The first sequence involved uneeded indention, and implication that step3 is a sub-step of step 2 which is a sub-step of step 1, when they are really at the same level. IMO, it's a lot easier to find exit0 than to find that right brace, especially if the indentation is messed up."
    I disagree. Fundamentally, the subsequent if statements do depend on each other. This dependence is explicit. I think the indentation should be preferred because it illustrates this fact. It's only if you think in terms of the GOTO that it seems that those steps are on the same level... they're not.

    "I assume you mean one main loop per function, not per program."
    False. I suggest you read the proof of Boehm and Jacopini. Any algorithm which can be described using a flowgraph can be written using a single while loop and if-then-else structures. Any recursive algorithm can be written as an iterative algorithm... so recursive functions aren't exempt from Boehm-Jacopini.

    "On a somewhat related issue, I prefer to use pointer to functions as opposed to state variables (switch case) for deferred actions, as it allows a series of small functions to be sequentially located in a source file rather than tied into the switch case statement for some common message handler. If I need to add a step, I don't have to edit the common message handler as it just calls a pointer to function. C++ implements the equivalent in it's classes, for C, structures can have pointers to functions."
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook