Gcc 4.8.3没有发现丢失的"return"关键字 [英] Gcc 4.8.3 does not spot missing 'return' keyword

查看:60
本文介绍了Gcc 4.8.3没有发现丢失的"return"关键字的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

让我们看一下这样的代码:

Let's look at such piece of code:

#include <iostream>

int foo(int i) {return i; }

int foobar(int z) {return foo(z);}

int main() {
std::cout << foobar(3) << std::endl;
}

使用g ++ -std = c ++ 11可以很好地编译并给出输出3.但是相同的输出由以下给出:

It compiles fine with g++ -std=c++11 ... and gives output 3. But The same output is given by:

#include <iostream>

int foo(int i) {return i; }

int foobar(int z) { foo(z);}

int main() {
std::cout << foobar(3) << std::endl;
}

它编译没有问题,但是很明显,foobar中缺少关键字return.它是gcc 4.8.3中的错误,还是我不了解某些c ++ 11原理?(在Fedora 20上运行)

It compiles without problems but clearly the keyword return is missed in foobar. Is it a bug in gcc 4.8.3 or maybe I'm not aware of some c++11 principle? (Runned on Fedora 20)

推荐答案

C ++标准没有要求编译器在函数返回非时坚持使用 return 语句.无效.相反,在没有 return 语句的情况下从此类函数的结尾流出是未定义的行为.该标准中的相关语句位于6.6.3 [stmt.return]第2段的最后一句中(而3.6.1 [basic.start.main]第5段中的语句则使 main()退出此功能):

The C++ standard doesn't make a mandate for compilers to insist on a return-statement in functions return non-void. Instead, flowing off the end of such a function without a return-statement is undefined behavior. The relevant statement in the standard is in 6.6.3 [stmt.return] paragraph 2, last sentence (and in 3.6.1 [basic.start.main] paragraph 5 is the statement making it OK for main() to flow off this function):

从函数末尾流出就等于没有值的返回;这会导致返回值函数的行为不确定.

Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.

这种方法的主要原因是,如果函数实际上真正返回了,那么它可能是不平凡的,甚至是不可能的.考虑以下函数声明和函数定义:

The primary reason for this approach is that it may be non-trivial or even impossible if the function actually ever really returns. Consider this function declaration and function definition:

extern void will_always_throw();
int does_not_return_anything() {
    will_always_throw();
}

假设 will_always_throw()确实如其名,确实没有错.实际上,如果编译器变得更聪明,并且设法验证 will_always_throw()的确会始终抛出(或将 will_always_throw(),可能会警告永远不会到达此定义中的最后一条语句:

Assuming will_always_throw() indeed does as the name suggests, there is nothing wrong. In fact, if the compiler gets smarter and manages to verify that will_always_throw(), indeed, always throws (or a "noreturn" attribute is attached to will_always_throw(), it may warn about the last statement in this definition never being reached:

int does_return_something_just_in_case() {
    will_always_throw();
    return 17;
}

处理这些情况的一般方法是使编译器支持适当的选项,以便在需要时启用/禁用警告.例如,在您的代码上,我可以使用的所有编译器( gcc clang icc )在启用警告的情况下创建警告(前两个使用 -Wall ,英特尔编译器使用 -w2 ).

The general approach to deal with these situations is for compilers to support suitable options enabling/disabling warnings as necessary. For example, on your code all compilers I have access to (gcc, clang, and icc) create a warning assuming warnings are enable (using -Wall for the first two and -w2 for Intel's compiler).

这篇关于Gcc 4.8.3没有发现丢失的"return"关键字的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆