Pointless Warning?

I have code similar to this:

Code:

int menu()
{
   switch ( do somthing )
  {
  case 1:
     // blah
    break;

   case 2:
      return 0;
      break;
   }
}

Techniclly, all above is fine, the function asks for a return value and would recieve it if option 2 was executed.

When I compile. I have several functions that ask for a integer value to be returned, and I do this, but get this bizzare warning:

main.cpp(400) : warning C4715: 'beginTheGame' : not all control paths return a value

I just dont understand it?

If do something is anything else than 2, your function will return nothing.
Far from pointless. Consider adding a default case with some return value and an assert (and a return to case 1).
Or just add a default return for those cases that doesn't returning anything explicit.

It's just letting you know there may be extraneous code. That error doesn't stop it from running, but if you want to get rid of it you should return a dummy value. Say under case 1, if the blah executes, return 2, otherwise return 0.

What do you think that your function will return if "do somthing" is 1 ?.
Kurt

Assuming the do something resolves to an integer value, this function as posted will only return a value if do something resolves to 2. Any other value and the function ends with the last } with no return statement.

[edit]Wow, 3 posts beat me to it. Talk about quick response![/edit]

Thank you guys, very quick replys. I understand it now.

Originally Posted by swgh

I have code similar to this:

Code:

int menu()
{
   switch ( do somthing )
  {
  case 1:
     // blah
    break;

   case 2:
      return 0;
      break;
   }
}

Techniclly, all above is fine, the function asks for a return value and would recieve it if option 2 was executed.

since when we have this feature in c++ of optional returns

AFAIK, C++ doesn't enforce all return paths to return a value (does it?), but does enforce that every function must at least ensure that one value is returned, even if it means just one path out of many.

Well, there may be cases where only the handled cases should occur and anything else would constitute invalid input. In such cases a throw or assert(false) might be used to make sure that execution doesn't reach the end of the function without returning a value:

Code:

//valid values for in are [0, 2]
int translate(int in)
{
    switch (in) {
        case 0:
            return 10;
        case 1:
            return 42;
        case 2:
            return 144;
    }
    throw InvalidInput;
}

(Of course this code could be structured differently.)

C++ requires that a function with a return type always returns a value or not return at all (throw an exception, longjmp() out, abort the program).
However, it doesn't require a diagnostic for a violation of this rule, because it's too complicated to enforce, and C++ trusts the programmer more than the compiler. Consider:

Code:

int foo()
{
  if(complicated_condition()) {
    bla bla bla;
    do_the_switch = true;
  }
  more code;
  if(!do_the_switch) return 0;

  switch(something())
  { // under complicated_condition(), something() can only return 1, 2 or 3
  case 1: return 100;
  case 2: return 200;
  case 3: return 300;
  default: assert(!"something() returned unexpected value");
  }
}

The compiler would have to do a lot of work to track down the relationship between complicated_condition() and something()'s return value. It would have to analyze the data flow across procedures, potentially even taking global state into account, and with the need to prove that it cannot change between the calls in a way that would change the outcome. Only then can it say with certainty that the function does not return a value under some circumstances.

Therefore, C and C++ compilers are not required to give diagnostics.

Java and C#, on the other hand, don't trust the programmer. Their language standards dictate that the compiler must implement some very simple flow analysis and that functions must return a value or throw along every path deemed possible by this method. (And that variables are initialized before use, using the same heuristic. Another thing C++ doesn't require, although it says that accessing an uninitialized variable is undefined.)

GCC uses the following method, I think:
1) If the compiler can prove that a possible way returns no value, it gives an error, but only in standard mode (there is old code that doesn't always return a value for int functions, and GCC needs to maintain compatibility). Typically, that means that the function contains no return statement at all.
2) If the compiler can prove that a possible way returns no value, and it's not in standard mode, it gives a warning.
3) If the compiler thinks it's possible that a path that returns no value is taken, and -Wextra is specified, it gives a warning.
4) Otherwise, no warning is emitted.

Other than the excuse of it being too much work for the compiler to check (which I think it a pretty lousy excuse), why would the C++ committee allow bugs like this to go unnoticed by the compiler?
I NEVER trust the programmer over the compiler (unless the programmer is me of course ). Luckily most good compilers I've seen should give a warning about "not all control paths return a value", although you might need to turn the warning level up beyond the default.

CornedBee, I don't see how your example demonstrates complicatedness (sp?!). I can see just by looking at that function that all paths have either a return or an assert.

Originally Posted by robwhit

CornedBee, I don't see how your example demonstrates complicatedness (sp?!). I can see just by looking at that function that all paths have either a return or an assert.

Exactly. All you need to do is start looking from the bottom of the function going up. If you see code before a return (going up of course) and it isn't something that would end the function, you have a control path without a return.
BTW, what exactly would it return if you don't specify a return statement? Does it default to 0 or is it some garbage in memory?

Well, for one thing assert would not be there if NDEBUG is defined...

Can the compiler find out that something() can return only 1, 2 or 3?

Originally Posted by anon

Well, for one thing assert would not be there if NDEBUG is defined...
Can the compiler find out that something() can return only 1, 2 or 3?

I doubt that. It would only look inside the current function, and look for a default (or a return just before the end of the function), but I may be wrong.
But an assert would certainly not get rid of the warning...

Originally Posted by cpjust

Exactly. All you need to do is start looking from the bottom of the function going up. If you see code before a return (going up of course) and it isn't something that would end the function, you have a control path without a return.
BTW, what exactly would it return if you don't specify a return statement? Does it default to 0 or is it some garbage in memory?

That would be undefined, wouldn't it?
Just like void main.