views:

211

answers:

7

Given a function like so

bool RequestStatus()
{
    ...
    if (code == myCode) {
         return true;
    } else {
         return false;
    }
}

Why would the compiler complain that "Function should return value". Unless I am missing something, how else could it not return true or false? Is it because the value of myCode is runtime dependent so the compiler is not sure on the logical paths?

+17  A: 

if you write return (code == myCode); you will save lines, make the compiler happy, and generally be writing in a more C++-ish style.

Kate Gregory
True, but that doesn't answer the question.
uncle brad
I don't know that exact compiler but to avoid the error the compiler would have to sort of count on its fingers whether every possible path (the if and the else of that if) returns something. It seems like it's happier finding a line outside any conditions that returns. Rewriting into a single line with no if will, as I said, make the compiler happier.
Kate Gregory
+5  A: 

It would be more elegant to do

bool RequestStatus()
{
    return code == myCode;
}

That may eliminate your compiler message/warning.

JAB
+8  A: 

VC++ and g++ will not give a warning message if all branches have a return statement. I guess your compiler (c++-builder-5) can't check properly to determine if there is a return point on all branches. Or there is another condition somewhere that you aren't showing us that doesn't have a return statement.

You can probably trivially refactor your code (which is probably similar to the posted code) to have one return point which will avoid the warning for your compiler.

Brian R. Bondy
Indeed. C++ Builder 5 does not exhaustively check such conditions. (Not like C# where the specification itself _mandates_ they be caught !).And avoiding such warnings with C++ Builder is not always easy, because what the compiler checks depends on the compilation options. Fix the warning in debug build and it sometimes comes back in release build, and conversely :-(
Thanks Brian - I ended up refactoring the whole thing and it is much better now
0A0D
+4  A: 

I'd imagine it is a compiler misgiving. You are in nested scope and the compiler is probably checking for a return statement in function scope.

In your example:

bool RequestStatus()
{
    ...
    if (code == myCode) {
         return true;
    } else {
         return false;
    }
}

What happens after the if statement? You need a return statement at the end of the function so that all paths of execution are covered. You can refactor the code like this:

bool RequestStatus()
{
    ...
    if (code == myCode) {
         return true;
    } 

    // else 
    return false;
}

or even

return (code == myCode) ? true : false;

But the other suggestion of

return ( code == myCode );

is cleaner.

Konrad
Ah, but if logic 1 doesn't pass, then logic 2 will pass so why put a return statement at the end?
0A0D
Well, in this case, I think most of us will agree that *nothing* happens after the 'if' statement (hence the OP's question..)
phtrivier
+5  A: 

Subjectively I agree with the posters saying you should refactor this into a neat x == y return statement, however there is nothing wrong with the code. It's your compiler.

Stefan Valianu
+1  A: 

The following will also likely clear the compiler message/warning.

bool RequestStatus()
{ 
   ...

   if (code == myCode) 
      return true;

   return false;
}
Dave M
A: 

Hi,

Is your code really as simple as the snippet you just posted ?

In Delphi (also a Borland/CodeGear/Embarcadero product), I encountered the same "problem" on a piece of wtf code, which was actually a nested-ifs-hell :

if test1 then
  if test2 then
    if test3 then
      if test4 then
        if test5 
          then ...
          else ...
      else
        if test5 
          then ...
          else ...
    else
      if test4 then
        if test5 
          then ...
          else ...
      else
        if test5 
          then ...
          else ...
//etc...

(There were really 5 levels of nested ifs...) The compiler simply sent the warning if there were too many possible branches.

You can also have the warning if your code is inside a try/except block, and there is an execution path going through an exception which doesn't initialize your result.

LeGEC
@LeGEC: It actually is that simple
0A0D