• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

function calling with an if statement?

A

alyarb

Platinum Member
my latest programming assignment has us writing several small programs and putting them all into one .c file selectable from a main menu. i've got everything done except the menu. i want the menu to come up, scanf for a choice, and then use if statements to call the proper function, but i can't find the syntax anywhere for doing this, and

if (mode == 1) {double arithGame(int max, int quantity, int op);}

doesn't do anything. should i be using goto? because i've never used that. what am i doing wrong here?
 
if (mode == 1)
.....arithGame( max, quantity, op);


I can't think of any reason to ever use a goto in a high-level language, and as far as I know, it's looked down upon.
 
Originally posted by: nkgreen
if (mode == 1)
.....arithGame( max, quantity, op);


I can't think of any reason to ever use a goto in a high-level language, and as far as I know, it's looked down upon.
Click to expand...

Very looked down upon.

Your arthGame function is returning a double (Im actually surprised your compile let you get away with that syntax) If you want to use the return value then you could say something like

double value = arthGame(stuff);
 
Originally posted by: nkgreen
if (mode == 1)
.....arithGame( max, quantity, op);


I can't think of any reason to ever use a goto in a high-level language, and as far as I know, it's looked down upon.
Click to expand...

They actually can be useful at times (as in they actually improve code readability), but those times are typically rare. As with all things, they can be used properly or improperly.
 
Originally posted by: esun
Originally posted by: nkgreen
if (mode == 1)
.....arithGame( max, quantity, op);


I can't think of any reason to ever use a goto in a high-level language, and as far as I know, it's looked down upon.
Click to expand...

They actually can be useful at times (as in they actually improve code readability), but those times are typically rare. As with all things, they can be used properly or improperly.
Click to expand...

Sorry, but if a code segment becomes more readable with a goto, then it wasn't very well thought out. There is no reason for a goto in a modern language.
 
Originally posted by: Cogman
There is no reason for a goto in a modern language.
Click to expand...

Well, I cannot resist.

Djikstra did not intend for us to never us goto's when he wrote Goto considered harmful. Just to use them in way that doesn't hang ourselves.

Don't abhor the goto. It can be readable -- it can take nasty code out-of-line:
if(error) goto handler_down_below_but_in_the_same_function;

A goto is just an abstraction of a lower-level feature of the underlying machine: the jump. Goto is like a pointer in some respects. There's plenty of code that doesn't use pointers, either -- Python for instance. But then again, there's lots of C out there, too.

But don't take my word for it:
Linus Torvalds on Gotos: http://kerneltrap.org/node/553/2131
Gotos for getting error handling out of the way: http://www.perlmonks.org/?node_id=181789
Gotos for flexibility and performance: http://netevil.org/blog/2004/jul/goto-isnt-evil
 
Originally posted by: degibson
Originally posted by: Cogman
There is no reason for a goto in a modern language.
Click to expand...

Well, I cannot resist.

Djikstra did not intend for us to never us goto's when he wrote Goto considered harmful. Just to use them in way that doesn't hang ourselves.

Don't abhor the goto. It can be readable -- it can take nasty code out-of-line:
if(error) goto handler_down_below_but_in_the_same_function;

A goto is just an abstraction of a lower-level feature of the underlying machine: the jump. Goto is like a pointer in some respects. There's plenty of code that doesn't use pointers, either -- Python for instance. But then again, there's lots of C out there, too.

But don't take my word for it:
Linus Torvalds on Gotos: http://kerneltrap.org/node/553/2131
Gotos for getting error handling out of the way: http://www.perlmonks.org/?node_id=181789
Gotos for flexibility and performance: http://netevil.org/blog/2004/jul/goto-isnt-evil
Click to expand...

I prefer structured exception handling as a way to move error handling to a reasonable place... but then what is a "throw" statement if not a modern goto?
 
Originally posted by: Markbnj
Originally posted by: degibson
Originally posted by: Cogman
There is no reason for a goto in a modern language.
Click to expand...

Well, I cannot resist.

Djikstra did not intend for us to never us goto's when he wrote Goto considered harmful. Just to use them in way that doesn't hang ourselves.

Don't abhor the goto. It can be readable -- it can take nasty code out-of-line:
if(error) goto handler_down_below_but_in_the_same_function;

A goto is just an abstraction of a lower-level feature of the underlying machine: the jump. Goto is like a pointer in some respects. There's plenty of code that doesn't use pointers, either -- Python for instance. But then again, there's lots of C out there, too.

But don't take my word for it:
Linus Torvalds on Gotos: http://kerneltrap.org/node/553/2131
Gotos for getting error handling out of the way: http://www.perlmonks.org/?node_id=181789
Gotos for flexibility and performance: http://netevil.org/blog/2004/jul/goto-isnt-evil
Click to expand...

I prefer structured exception handling as a way to move error handling to a reasonable place... but then what is a "throw" statement if not a modern goto?
Click to expand...

What are if statements, while statements, for statements, any sort of statement that changes the position of the instruction pointer if not a modern goto? Arguing that we need goto's because modern instructions map down to them is like arguing that we need global variables because modern variables map down to them. (There are uses for globals, btw, more so then the goto statement).

With all these modern goto mappings, why would you use a goto? I've seen a lot of problems, and have yet seen one that a goto makes things better. Anything you would use a goto for you can use an if, case, while, break, continue, return, or even create a whole separate function to accomplish pretty much the exact same functionality. So why use it?
 
Originally posted by: Cogman
Originally posted by: Markbnj
Originally posted by: degibson
Originally posted by: Cogman
There is no reason for a goto in a modern language.
Click to expand...

Well, I cannot resist.

Djikstra did not intend for us to never us goto's when he wrote Goto considered harmful. Just to use them in way that doesn't hang ourselves.

Don't abhor the goto. It can be readable -- it can take nasty code out-of-line:
if(error) goto handler_down_below_but_in_the_same_function;

A goto is just an abstraction of a lower-level feature of the underlying machine: the jump. Goto is like a pointer in some respects. There's plenty of code that doesn't use pointers, either -- Python for instance. But then again, there's lots of C out there, too.

But don't take my word for it:
Linus Torvalds on Gotos: http://kerneltrap.org/node/553/2131
Gotos for getting error handling out of the way: http://www.perlmonks.org/?node_id=181789
Gotos for flexibility and performance: http://netevil.org/blog/2004/jul/goto-isnt-evil
Click to expand...

I prefer structured exception handling as a way to move error handling to a reasonable place... but then what is a "throw" statement if not a modern goto?
Click to expand...

What are if statements, while statements, for statements, any sort of statement that changes the position of the instruction pointer if not a modern goto? Arguing that we need goto's because modern instructions map down to them is like arguing that we need global variables because modern variables map down to them. (There are uses for globals, btw, more so then the goto statement).

With all these modern goto mappings, why would you use a goto? I've seen a lot of problems, and have yet seen one that a goto makes things better. Anything you would use a goto for you can use an if, case, while, break, continue, return, or even create a whole separate function to accomplish pretty much the exact same functionality. So why use it?
Click to expand...

I wasn't actually arguing that we need them, but I guess I was implying that anti-gotoism might not rest on very firm foundations. I haven't used a goto in 20 years, but sitting here I am having a hard time coming up with reasons why, assuming they are used carefully and in a structured manner, they are really so bad?

Let me ask another question: do you guys use multiple return statements out of a method or function (in languages that allow it)? I have always adhered to the single point of return model, but I work with some younger C# guys who have no problem returning out of the middle of a loop where I will use break; or from within a case statement. That, to me, is a goto. Is it wrong?
 
Originally posted by: Markbnj
I wasn't actually arguing that we need them, but I guess I was implying that anti-gotoism might not rest on very firm foundations. I haven't used a goto in 20 years, but sitting here I am having a hard time coming up with reasons why, assuming they are used carefully and in a structured manner, they are really so bad?

Let me ask another question: do you guys use multiple return statements out of a method or function (in languages that allow it)? I have always adhered to the single point of return model, but I work with some younger C# guys who have no problem returning out of the middle of a loop where I will use break; or from within a case statement. That, to me, is a goto. Is it wrong?
Click to expand...

I'm no expert or professional, but I usually return whenever it seems most convenient. I never do it in a loop (perhaps in a while loop, but just guessing), but I've done it in conditional statements. For readability, returning in a case seems better because it's right there and you don't need to read until the end. Small point, but whatever. In my classes, I can't recall a teacher stressing one over the other. Then again, I do go to a public university. 😛

A side note, I read Djikstra's goto thing, and was thoroughly confused. 🙁
 
Originally posted by: Markbnj
I wasn't actually arguing that we need them, but I guess I was implying that anti-gotoism might not rest on very firm foundations. I haven't used a goto in 20 years, but sitting here I am having a hard time coming up with reasons why, assuming they are used carefully and in a structured manner, they are really so bad?

Let me ask another question: do you guys use multiple return statements out of a method or function (in languages that allow it)? I have always adhered to the single point of return model, but I work with some younger C# guys who have no problem returning out of the middle of a loop where I will use break; or from within a case statement. That, to me, is a goto. Is it wrong?
Click to expand...

Lets put it this way, you haven't used it in 20 years, you haven't come up with a case that legitimately justifies the use of one. If there where a concrete situation where gotos make everything better, then by all means use them. However, I can't think of a single one that justifies the use of the archaic token.

If it does make your code more readable, then you almost always need to rewrite the code because the structure is bad.

If you have 20 years of experience in programming, and you legitimately think a goto belongs. So be it, it probably does. However, I'm against teaching it to new programmers. Its one of those things that almost never applies and should be learned out of necessity, not a "Hum, maybe I can use a goto here" sort of thing. It is weird because almost every new programmer knows about it, yet none of them should be using it.

As for the multiple returns. Rarely, but far more frequently then gotos. (my return statements are usually right next to each other). Single entry single exit keeps things pretty clean. I use multiple exits in situations like

bool evalVal(int value)
{
if (value == 3)
return true
else if (value == 2)
return false
else
return 7
}

Generally when the functions fit on one page.

IDK, I see the supporters of goto's as people clinging onto some strange syntax/feature that they never use but might be useful.. some day. People that know how to program pretty much never use it, and people that don't know, use it and regret it later.
 
If you have 20 years of experience in programming, and you legitimately think a goto belongs. So be it, it probably does. However, I'm against teaching it to new programmers. Its one of those things that almost never applies and should be learned out of necessity, not a "Hum, maybe I can use a goto here" sort of thing. It is weird because almost every new programmer knows about it, yet none of them should be using it.
Click to expand...

I have about 35 years of experience, if we count starting with BASIC in 1975. And you're right, I don't use them because I don't need them. In fact I really can't imagine getting myself into a situation where that structure makes sense anymore. The language tools have evolved beyond it.

So I will now back away from my brush with justifying goto and return to thinking it sucks.
 
Originally posted by: Markbnj
So I will now back away from my brush with justifying goto and return to thinking it sucks.
Click to expand...

🙂

I seem to have come in too late to add any value to this discussion, but I like the conclusion.

-chronodekar
 
Dang it, hate to resurrect the topic, but I have to say, my short sighted "Goto's are never good" thinking has come back to haunt me.

I've ran into a very specific and very valid use of goto that I really can see how to avoid without using one.

The problem? Exception loop handling. I want the program to save off errors that it encounters rather then just exiting out. Well, since the errors occur in a loop, there really isn't any way to get back into the loop after an error occurs without using a goto. (Perhaps I could split it off into a separate function and basically use recursion, but I don't really want to do that).

I guess I'll put goto's in the "avoid if possibly, but don't ignore" catagory.
 
Cogman said:
Dang it, hate to resurrect the topic, but I have to say, my short sighted "Goto's are never good" thinking has come back to haunt me.

I've ran into a very specific and very valid use of goto that I really can see how to avoid without using one.

The problem? Exception loop handling. I want the program to save off errors that it encounters rather then just exiting out. Well, since the errors occur in a loop, there really isn't any way to get back into the loop after an error occurs without using a goto. (Perhaps I could split it off into a separate function and basically use recursion, but I don't really want to do that).

I guess I'll put goto's in the "avoid if possibly, but don't ignore" catagory.
Click to expand...

Really? I'd love to see some pseudo-code. I bet we could design that goto away. Right off the bat it sounds like allowing the exception to propagate out of the loop is the problem. I would not allow the exception to leave the context of the loop unless it's occurrence prevented continued execution of the loop.
 
Markbnj said:
Really? I'd love to see some pseudo-code. I bet we could design that goto away. Right off the bat it sounds like allowing the exception to propagate out of the loop is the problem. I would not allow the exception to leave the context of the loop unless it's occurrence prevented continued execution of the loop.
Click to expand...

Humm, I guess it is possible, However, some of the difficulty comes in the fact that I am doing things 100 units at a time rather then 1 unit at a time, with an error, I would like to be able to single out the one.

It looks something like this

Code: 
try
   if (count > 100)
      step = 100;
   while (i < count)
   {
      dostuff(i, step);
      i += step;
      if (i + step > count)
         step = 1;
   }
catch
   DoErrorStuf();

This is currently how the code is setup. Right now it just displays the error and exits. (that's behavior I would like to change) the dostuff function is externally defined IE I don't have access to its source code. It is where the exceptions are generated.

the change I was thinking of would look something like this

Code: 
try
loopstart:
   if (count > 100)
      step = 100;
   while (i < count)
   {
      dostuff(i, step);
      i += step;
      if (i + step > count)
         step = 1;
   }
catch
   if (step > 100)
   {
      step = 1;
      goto loopstart;
   }
   else
   {
      saveErrorMessage();
      if (count - i > 100)
         step = 100;
      ++i;
      goto loopstart;
   }

mind you, in this case, using an exception inside the loop looks like it would simplify things, however, this is (obviously) not the complete loop. There is a lot of other stuff that HAS to go on inside the loop. So simply duplicating the loop code on an exception to track down the exception might not look too clean. (and would result in having to have a double exception).
 
alyarb said:
my latest programming assignment has us writing several small programs and putting them all into one .c file selectable from a main menu. i've got everything done except the menu. i want the menu to come up, scanf for a choice, and then use if statements to call the proper function, but i can't find the syntax anywhere for doing this, and

if (mode == 1) {double arithGame(int max, int quantity, int op);}

doesn't do anything. should i be using goto? because i've never used that. what am i doing wrong here?
Click to expand...

I'dd probably use a switch statement rather then a bunch of if's. It works the same, just more readable imho.
 
Cogman said:
Humm, I guess it is possible, However, some of the difficulty comes in the fact that I am doing things 100 units at a time rather then 1 unit at a time, with an error, I would like to be able to single out the one.

It looks something like this

Code: 
try
   if (count > 100)
      step = 100;
   while (i < count)
   {
      dostuff(i, step);
      i += step;
      if (i + step > count)
         step = 1;
   }
catch
   DoErrorStuf();

This is currently how the code is setup. Right now it just displays the error and exits. (that's behavior I would like to change) the dostuff function is externally defined IE I don't have access to its source code. It is where the exceptions are generated.

the change I was thinking of would look something like this

Code: 
try
loopstart:
   if (count > 100)
      step = 100;
   while (i < count)
   {
      dostuff(i, step);
      i += step;
      if (i + step > count)
         step = 1;
   }
catch
   if (step > 100)
   {
      step = 1;
      goto loopstart;
   }
   else
   {
      saveErrorMessage();
      if (count - i > 100)
         step = 100;
      ++i;
      goto loopstart;
   }

mind you, in this case, using an exception inside the loop looks like it would simplify things, however, this is (obviously) not the complete loop. There is a lot of other stuff that HAS to go on inside the loop. So simply duplicating the loop code on an exception to track down the exception might not look too clean. (and would result in having to have a double exception).
Click to expand...

Could you wrap the whole thing in a while loop?
Code: 
flag = true
while(flag==true){
  try{
    while(...){
      yourcode...
    }
  flag = false
  } catch{
    things...
    flag = true
  }
}
so when the original while() is done, flag<-false and it quits. If an exception is thrown, it's caught (flag=true here is redundant) and the while runs again.

Granted this really isn't any different than your code with goto since (i think) in assembly both versions will resolve to a jump command. Mine involves extra if-checks and an extra flag variable.
 
I always make my trys and catches as close to the possible offender. If you're calling buggy code, do your best to properly report, catch and throw things.

Code: 
bool bError=false;
int iReturn=0;
try
{            
	if(iReturn=dostuff(i, step)) 
	{
		// return is usually negative for system errors, 
		// postive for user errors
		// the best error checking is those you don't 
		// have to throw and catch.
		// ALWAYS CHECK RETURNS IF THEY SEND ERRORS
		bError=true;
	}
}
catch (Exception cException)
{
	bError=true;
	Console.WriteLine("Naughty: {0}", cException);
	// Exception is a class, you can usually 
	// get a lot of information out of it.
	...
	if(???) // Can I handle the exception otherwise rethrow it
	{
		bError=false; // continue
	} else {
		throw cException;	
	}
}
finally
{
	if(bError)
	{
		// clean up and report
		break; // loop(s)
	}
}
 
It isn't so much a problem with buggy code. The issue is that I'm dealing with LARGE amounts of user input, and like all user input, you never know what you are going to get out of it.

I'm coding in delphi, which, instead of nicely returning from the function with a zero or whatever fail value they use, decided instead that it is better to throw exceptions the moment the error occurs.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top