Why does this compile?

[exits funnel]

Hello,

I was playing around a accidently realized that the following compiles:

//BEGIN CODE
class foo
{
public:
void push(int* iptr) { }
int* peek( )const { }
int* pop( ) { }
};

int main( ) { }
//END CODE

I would expect the compiler to complain because, for example, peek( )
doesn't return an int* or anything else for that matter. If I add
something like 'return 4;' to peek( ) the compiler complains as expected
about the return type mismatch so the empty case seems to be something
special. If anyone could shed some light I'd appreciate it. Thanks in
advance.

-exits

 

[Rolf Magnus]

Hello,

I was playing around a accidently realized that the following
compiles:

//BEGIN CODE
class foo
{
public:
void push(int* iptr) { }
int* peek( )const { }
int* pop( ) { }
};

int main( ) { }
//END CODE

I would expect the compiler to complain because, for example, peek( )
doesn't return an int* or anything else for that matter. If I add
something like 'return 4;' to peek( ) the compiler complains as
expected about the return type mismatch so the empty case seems to be
something
special. If anyone could shed some light I'd appreciate it. Thanks
in advance.

The compiler is not required to issue an error message (though a good
one should at least print a waring if you enable all the diagnostic
options), but returning nothing from a function with non-void return
type invokes undefined behaviour.

 

[Sam Holden]

Hello,

I was playing around a accidently realized that the following compiles:

//BEGIN CODE
class foo
{
public:
void push(int* iptr) { }
int* peek( )const { }
int* pop( ) { }
};

int main( ) { }
//END CODE

I would expect the compiler to complain because, for example, peek( )
doesn't return an int* or anything else for that matter. If I add
something like 'return 4;' to peek( ) the compiler complains as expected
about the return type mismatch so the empty case seems to be something
special. If anyone could shed some light I'd appreciate it. Thanks in
advance.

Your compiler sucks.

Or you haven't turned warnings on.

Leaving it off isn't an error according to the language (at least as
far as I recall).

 

[Ron Natalie]

Hello,

I was playing around a accidently realized that the following compiles:

Falling off the end of a non-void returning function is undefined behavior.
The compiler is NOT required to diagnose this. This case is trivial. But
imagine a more complex function:
int* peek() {
while(some_condition()) {
blah();
if(some_other_condition()) return foobar();
}
// do we ever get here;
}

 

[exits funnel]

Your compiler sucks.

Or you haven't turned warnings on.

Leaving it off isn't an error according to the language (at least as
far as I recall).

It's true that if I turn the warning level up, the compiler does warn me
about missing return statements but the question still remains (assuming
my compiler is compliant with the spec): Why is a return type mismatch
an error while no return statement at all isn't? What's the rationale?

-exits

 

[Sam Holden]

It's true that if I turn the warning level up, the compiler does warn me
about missing return statements but the question still remains (assuming
my compiler is compliant with the spec): Why is a return type mismatch
an error while no return statement at all isn't? What's the rationale?

Becsaue a return type mismatch causes a type error, but a missing return
might be intended. There's already a reply giving an example of a case
in which leaving off the return might be valid.

Note: Java requires the return, and the idiot compiler not noticing that
the end of a function was unreachable was enough to drive me mad (I
dislike being forced to add the extra code which will never be executed
and the comment required to warn future readers of why the code was
added...

 

[Cy Edmunds]

Hello,

I was playing around a accidently realized that the following compiles:

//BEGIN CODE
class foo
{
public:
void push(int* iptr) { }
int* peek( )const { }
int* pop( ) { }
};

int main( ) { }
//END CODE

I would expect the compiler to complain because, for example, peek( )
doesn't return an int* or anything else for that matter. If I add
something like 'return 4;' to peek( ) the compiler complains as expected
about the return type mismatch so the empty case seems to be something
special. If anyone could shed some light I'd appreciate it. Thanks in
advance.

-exits

My compiler (VC++.Net) also compiles your code without an error. But if I
try to use one of the bogus functions it gives an error:

foo duh;
int *p = duh.peek();

gives me the error:

error C4716: 'foo:eek' : must return a value

 

[Jorge Rivera]

Becsaue a return type mismatch causes a type error, but a missing return
might be intended. There's already a reply giving an example of a case
in which leaving off the return might be valid.

I have not seen this reply.
Would you mind restating what is so valid about ignoring the return type
of a function or method that you design?????

Note: Java requires the return, and the idiot compiler not noticing that
the end of a function was unreachable was enough to drive me mad (I
dislike being forced to add the extra code which will never be executed
and the comment required to warn future readers of why the code was
added...

I agree that the compiler should catch those return errors, however, I
fail to understand why ignoring the return type of a function is such a
a great idea.

Jorge L.

 

[Rolf Magnus]

I have not seen this reply.
Would you mind restating what is so valid about ignoring the return
type of a function or method that you design?????

If your function will never reach a certain place, it's just unecessary
if you need to write a return statement for that unreachable part. For
example:

string foo(const string& s)
{
if (s == "blah")
return do_something();
else if (s == "whatever")
return do_something_else();
else
return some_error;

// this part can never be reached. Why should one be forced to
// add a return statement here?
}

If you add that return, some compilers will even warn you about the fact
that you wrote unreachable code.

I agree that the compiler should catch those return errors, however, I
fail to understand why ignoring the return type of a function is such
a a great idea.

Ignoring it generally isn't, but in specific situations, it is better
than needing to write unreachable code. In my above example, the
compiler could easily find out that the code is unreachable, but it's
not always so obvious, so a programmer might indeed intend to omit a
return because he knows that it can't ever be reached, or at least
shouldn't ever be reached. In the latter case, it makes more sense to
add an assert instead of a return. The compiler might not be able to
know that this place in the function won't never be reached.

 

[tom_usenet]

I have not seen this reply.
Would you mind restating what is so valid about ignoring the return type
of a function or method that you design?????

int f()
{
this_function_is_guaranteed_to_throw();
}

or

int f(T t)
{
switch(t)
{
case 1:
return something;
case 2:
return something_else;
default:
assert(("Should never get here", false));
}
}

Why should the compiler complain and require a bogus return just to
shut it up? The bogus return will probably add unnecessary machine
code to your executable, contributing to code bloat.

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html