Quote:
Originally Posted by anishakaul
GDB can be used for figuring out the control flow of the program which is IMHO enough for understanding why the output was wrong.
|
Are we talking about the program in post #22 of this thread?
Did you see a bug in that program that would be made more understandable by seeing the flow of control? I didn't.
I don't know the intention of most of the computations, so I can't guess whether there are any bugs in the decision making or in the computations. The collection of
if statements looks pretty bad when posted without CODE tags, and superficially looks like there are too few uses of
else for the number and contiguity of the uses of
if. But if you paste that into any tool that fixes the formatting, you can easily see that all the uses of
if and all the apparent failures to use
else are plausible for correct code. None of that looks particularly like a bug.
I'm assuming (because the OP gave so little detail about what was fixed in post #30) that the main problem was in the use of scanf. The output of the program was already plenty of information to see that scanf was producing unexpected results. Seeing the control flow in GDB would provide zero additional information about this problem. Using print instructions in GDB (when you know how and when they work consistently enough to trust) would be a trivial amount of extra info (beyond what the output of the program already gave) toward realizing that the use of scanf was the problem.
First rule of debugging: If you used scanf and your program doesn't work, probably the use of scanf was wrong. Check that first.
First rule of testing: If you used scanf and your program does work, probably you haven't tested the cases that reveal that your use of scanf was wrong. Use more imagination in selecting test cases.
BTW, I have a comment on most of the instances of missing
else in that code. The typical example is:
Code:
...
if(customer == 'u')
discount = 7.5;
else if(customer == 'i')
....
The
else was missing in the actual code.
That tends to be a time/space trade off (the code averages faster with the
else and smaller without it but the end result is the same).
This is a situation with no reason to care about either the time or the space of having vs. skipping that
else. If you did care, then depending on the cache line alignment and cache status of the code and the expected distribution of values, the smaller apparently slower code without the
else might actually be faster. So if I correctly understood dwhitney67's comment, I disagree. There was no reason to prefer if-else.
Quote:
Originally Posted by dwhitney67
Exercise your knowledge of the if-else construct a bit more. I see that you are aware of it, but you fail to use it when checking the value of the microprocessor type (mptype) and the customer value.
|
But the other part of that was a more reasonable suggestion:
Quote:
|
Alternatively, you could also look into using a switch directive.
|
I don't personally find the use of
switch more readable in this example than the mutually exclusive if conditions. But I can understand the viewpoint that does see
switch as more readable/maintainable.
