Can a function make calls to 2 other functions?

One of my functions makes a call to a function near the beginning of it's code, and then towards the end it makes a call to a DIFFERENT function.

The first call works just fine, but the second call doesn't seem to be happening at all.

Here it is:

Code:

int scoreFunct(char c, char team, int gameA, int gameB){
  
  while((c = getchar()) != EOF){

    if ((c == 'S') || (c == 's')){
      printFunct(scoreA,scoreB,c,team,gameA,gameB);
      return(PRINT);
    }  
        
    else if((c == 'B') || (c == 'b')){
      if(scoreB < 30){
        scoreB+=15;
      }  
      else if(scoreB == 30){
        scoreB+=10;
      }
      else if(scoreB == 40){
        gameFunct(char c, char team, int gameA, int gameB);
        return(GAME_B);
        scoreB = scoreB - scoreB;  //Since scoreB is a global variable, we need to reset it to 0 after the game to start the new score for next game
      }  
    }  
    else if((c == 'A') || (c == 'a')){
      if(scoreA < 30){
        scoreA+=15;
      }  
      else if(scoreA == 30){
        scoreA+=10;
      }
      else if(scoreA == 40){
        gameFunct(char c, char team, int gameA, int gameB);
        return(GAME_A);
        scoreA = scoreA - scoreA;  //Since scoreA is a global variable, we need to reset it to 0 after the game to start the new score for next game
      }  
    }
  }      

  return(0);
}

Yes, it can. I don't see why you'd expect more than one of the function calls to actually happen, though, if you look at the control structures you have there.

If you ask yourself what if/else if/else does, as well as what return does, you'll see why only one of your functions are being called.

Hmm, can't figure it out, is it because u can't call a function inside a cascading else if statement?

I kind of wonder how people manage to write programs they can't explain the logic for. Without really reviewing your code, from the comments of the other people, they are stating that you have written your conditions in such a way that you will never call both functions as you wish, which means you designed the function wrong.

If you can't explain the logic of the function to yourself in great detail with what each step is doing, then start over. You can tell your program to do things upon conditions that are impossible, so you have to make sure you know what you're doing with each condition.

Originally Posted by MacGyver

I kind of wonder how people manage to write programs they can't explain the logic for. Without really reviewing your code, from the comments of the other people, they are stating that you have written your conditions in such a way that you will never call both functions as you wish, which means you designed the function wrong.

If you can't explain the logic of the function to yourself in great detail with what each step is doing, then start over. You can tell your program to do things upon conditions that are impossible, so you have to make sure you know what you're doing with each condition.

Well perhaps...but when I wrote it, it made sense to me, hence why I wrote it like that, I wouldn't have written it if it didn't make sense to me :S

Not going to rewrite the whole function, cause that would mean a lot of work again lol, but I just managed to solve it without calling another function.

BTW, in the last 2 else if blocks, you have scoreB = scoreB - scoreB; and scoreA = scoreA - scoreA; directly AFTER a return statement. Since that code will NEVER be executed, should it come before the return statements or be removed completely?
If you set your compiler to the highest warning level, it should help you catch bugs like that.

> but the second call doesn't seem to be happening at all.
That's because some of them are prototypes, not calls.

Originally Posted by Salem

> but the second call doesn't seem to be happening at all.
That's because some of them are prototypes, not calls.

Yea thats because I had made changes to my code and then I decided to ask about the functions question, I had to re-edit to how it was before, it wasn't a prototype when I was actually programming, just forgot to remove the int's and char's when editing it for posting here, it doesn't matter anyways.

A few comments:
1. Don't EVER do "a = a - a". It makes the code harder to read, but it doesn't help anything - you may think "I'm so clever here", but no one who understands anything about programming will think you are clever writing something like this. [Same applies for zeroing by multiplying with zero, xor with self, and with zero or adding negative self]

If the processor for some reason performs a "zero this" faster by subtracting, the compiler will (assuming a good compiler) produce code to do a subtract operation instead of "load zero into this variable". Most likely the compiler will just do the above into a "oh, they are equal, let's just set a to zero" in the most efficient way it can anyways - but it's possible that the compiler actually produces a subtract operation.

2. As others pointed out, returning before a statement means "dead code" - it willl never be executed.

3. It will never call both of those functions - it will call one or the other, based on the if/else structure. I expect that to be the CORRECT behaviour from what I understand of your code. I don't see anything obviously wrong (assuming you actually have function calls instead of prototypes). Perhaps you could post your latest code, and also a description of exactly what is happening.

4. For future reference: adding debug statements to print out what a variable contains or trace ( e.g printf("At A\n"); ... printf("At B\n"); ) at suitable places in the code can very much help understand where the code ends up and why it's broken.

5. Addding code to cover unexpected behaviour can help a lot: Check for values outside the valid range (e.g. check scoreA, scoreB to ensure they have valid values). This will both catch logical errors, and make your code more robust if someone does something unexpected - e.g. "bad input".

--
Mats

Originally Posted by matsp

A few comments:
1. Don't EVER do "a = a - a". It makes the code harder to read, but it doesn't help anything - you may think "I'm so clever here", but no one who understands anything about programming will think you are clever writing something like this. [Same applies for zeroing by multiplying with zero, xor with self, and with zero or adding negative self]

Huh? I just did that because setting scoreA = 0; gave me a warning: statement with no effect


If the processor for some reason performs a "zero this" faster by subtracting, the compiler will (assuming a good compiler) produce code to do a subtract operation instead of "load zero into this variable". Most likely the compiler will just do the above into a "oh, they are equal, let's just set a to zero" in the most efficient way it can anyways - but it's possible that the compiler actually produces a subtract operation.

2. As others pointed out, returning before a statement means "dead code" - it willl never be executed.

3. It will never call both of those functions - it will call one or the other, based on the if/else structure. I expect that to be the CORRECT behaviour from what I understand of your code. I don't see anything obviously wrong (assuming you actually have function calls instead of prototypes). Perhaps you could post your latest code, and also a description of exactly what is happening.

no point now, it was due in 14 minutes ago, already submitted, but thanks for offering to help!

4. For future reference: adding debug statements to print out what a variable contains or trace ( e.g printf("At A\n"); ... printf("At B\n"); ) at suitable places in the code can very much help understand where the code ends up and why it's broken.

5. Addding code to cover unexpected behaviour can help a lot: Check for values outside the valid range (e.g. check scoreA, scoreB to ensure they have valid values). This will both catch logical errors, and make your code more robust if someone does something unexpected - e.g. "bad input".

--
Mats[/QUOTE]

Huh? I just did that because setting scoreA = 0; gave me a warning: statement with no effect

It had no effect due to the premature return.

Originally Posted by laserlight

It had no effect due to the premature return.

And I wonder why it didn't realize that the statement had no effect when it was changed... Poor compiler, I guess...

--
Mats