no return statement in function returning non-void
Today's cvs appears to have a number of warnings, this one (at least) seems to be a mistake: ./boost/wave/cpplexer/cpp_lex_token.hpp:208: warning: no return statement in function returning non-void
Doh! Some evil gremlin stole the return keyword... Thanks for pointing this out, it's fixed in CVS now. Regards Hartmut
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Neal Becker Sent: Monday, April 30, 2007 12:59 PM To: boost@lists.boost.org Subject: [boost] no return statement in function returning non-void
Today's cvs appears to have a number of warnings, this one (at least) seems to be a mistake:
./boost/wave/cpplexer/cpp_lex_token.hpp:208: warning: no return statement in function returning non-void
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Isn't it odd that this nonsense is legal c++?
Yes, sort of. Consider: double foo(blah blah blah) { blah blah blah if (x >= 0) return std::sqrt(x); throw std::domain_error("x was negative in foo"); } Here static analysis can tell you that control can never reach the }. But what if we put the throw into a separately compiled function? if (x >= 0) return std::sqrt(x); throw_domain_error("x was negative in foo"); Now the programmer may know, even though the compiler cannot, that control still cannot reach the }. What would have standard do? Force the programmer to insert a return statement that the programmer knows can never be executed? Worse: The C89 standard allows this: double f() { /* no return */ } int main() { f(); return 0; } In other words, a C function that claims to return non-void is allowed to fall off the end as long as its caller does not attempt to use the function's value. Which means that if C++ required a function that returns non-void to throw an exception when falling off the end, it would introduce a C incompatibility. So maybe I'm agreeing that it's odd--but at least there's a reason for it.
Andrew Koenig wrote:
Isn't it odd that this nonsense is legal c++?
Yes, sort of. Consider:
double foo(blah blah blah) { blah blah blah if (x >= 0) return std::sqrt(x); throw std::domain_error("x was negative in foo"); }
Here static analysis can tell you that control can never reach the }. But what if we put the throw into a separately compiled function?
if (x >= 0) return std::sqrt(x); throw_domain_error("x was negative in foo");
Now the programmer may know, even though the compiler cannot, that control still cannot reach the }. What would have standard do? Force the programmer to insert a return statement that the programmer knows can never be executed?
Indeed, this can introduce a real dilemma. We have such code, and there isn't an obvious solution: If we put in such a return statement to make one compiler happy, another will complain because it correctly figured out by static analysis that the statement isn't reachable. Ah well, the joy of portable programming. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
participants (4)
-
Andrew Koenig -
Hartmut Kaiser -
Neal Becker -
Stefan Seefeld