Creating a Simple Calculator Program in C

[germana2006]

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?

// Program easy calculator

#include<stdio.h>

// Start the main program
int main (void)
{
//declaration of variables
double numb1, numb2, sol;
int op, menu;

begin: // Reference of the goto-
//To ask and read for the first number
printf("Give the first number:\n");
scanf("%lf",&numb1);

//Choice of one option: case1=+, case2=-, case3=*, case4=/
//First we have to break our program before case 5
//for that I use the do .. while loop

oper:
do { // do the next command while the condition is true
printf("Which operation do you want to do:\n");
printf("(1) Addition\n (2) Subtraction\n (3) Multiplication\n (4) Division\n");
scanf("%d",&op);
printf("Give the second number:\n");
scanf("%lf",&numb2);
switch (op){
//Addition of two numbers
case 1:
sol = numb1+numb2;
printf("The solution is:\n");
printf("sol=%lf\n",sol);
break;
//Subtraction of two numbers
case 2:
sol = numb1-numb2;
printf("The solution is:\n");
printf("sol=%lf\n",sol);
break;
//Multiplication of two numbers
case 3:
sol = numb1*numb2;
printf("The solution is:\n");
printf("sol=%lf\n",sol);
break;
//Division of two numbers
case 4:
//If the numb2 is 0, the division is not possible
if(numb2==0){
printf("The division is not possible!\n");
}
else{
sol = numb1/numb2;
printf("The solution is:\n");
printf("sol=%lf\n",sol);
}
break;
}
} while (op<=4);


/* The program should have a menu
* where one can choose one of this options
* (1) new calculation
* (2) other operation
* (3) finish */

printf("choose one option: (1) new calculation (2) other operation (3)finish \n");
scanf("%d",&menu);
if(menu==1 || menu==2 || menu==3){
if (menu==1){
goto begin;
}
if (menu==2){
numb1=sol;
goto oper;
}
if (menu==3){
printf("End");
}
}

return(0);
}

 

[mXSCNT]

"goto" is a bad idea. Rewrite it with while/for/do loops and functions instead.

 

[germana2006]

I have done with goto, because I don't know how can I do with other loop.

 

[Coin]

I have done with goto, because I don't know how can I do with other loop.

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).

 

[germana2006]

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.

 

[rcgldr]

My next step is to try to change the goto loop for one of the other you purpose.

I don't understand why most programmers are "anti-goto". ... moved to "goto" thread.

 

[mXSCNT]

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.

 

[AUMathTutor]

"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.

 

[rcgldr]

moved to the "goto" thread.

 

[AUMathTutor]

"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."
...