“缺少返回声明"，但我知道它在那里 [英] "missing return statement", but I know it is there

问题描述

假设我具有以下功能:

// Precondition:  foo is '0' or 'MAGIC_NUMBER_4711'
// Returns:       -1 if foo is '0'
//                 1 if foo is 'MAGIC_NUMBER_4711'
int transmogrify(int foo) {
    if (foo == 0) {
        return -1;
    } else if (foo == MAGIC_NUMBER_4711) {
        return 1;
    }
}

编译器抱怨缺少返回语句"，但我知道 foo 的值永远不会与 0 或 MAGIC_NUMBER_4711 不同，否则我的函数应没有定义的语义.

The compiler complains "missing return statement", but I know that foo never has different values than 0 or MAGIC_NUMBER_4711, or else my function shall have no defined semantics.

对此有哪些更可取的解决方案?这真的是一个问题吗，即标准怎么说?

What are preferable solutions to this? Is this really an issue, i.e. what does the standard say?

推荐答案

有时，您的编译器无法推断出您的函数实际上缺少 no 缺少返回值.在这种情况下，存在几种解决方案:

Sometimes, your compiler is not able to deduce that your function actually has no missing return. In such cases, several solutions exist:

假定以下简化代码(尽管现代编译器会看到没有路径泄漏，只是示例性的):

Assume the following simplified code (though modern compilers will see that there is no path leak, just exemplary):

if (foo == 0) {
    return bar;
} else {
    return frob;
}

重组代码

if (foo == 0) {
    return bar;
}
return frob;

如果您可以将if语句解释为一种防火墙或前提条件，则此方法很好.

This works good if you can interpret the if-statement as a kind of firewall or precondition.

if (foo == 0) {
    return bar;
} else {
    return frob;
}
abort(); return -1; // unreachable

相应地返回其他内容.该注释告诉程序员和您自己的伙伴为什么会出现这种情况.

Return something else accordingly. The comment tells fellow programmers and yourself why this is there.

#include <stdexcept>

if (foo == 0) {
    return bar;
} else {
    return frob;
}

throw std::runtime_error ("impossible");

单功能出口点的缺点

控制流程流

有些回退到按功能返回一次又称单功能退出点作为解决方法.在C ++中，这可能被视为过时的，因为您几乎永远不知道该函数将在哪里真正退出:

Disadvantages of Single Function Exit Point

flow of control control

Some fall back to one-return-per-function a.k.a. single-function-exit-point as a workaround. This might be seen as obsolete in C++ because you almost never know where the function will really exit:

void foo(int&);

int bar () {
    int ret = -1;
    foo (ret);
    return ret;
}

看起来不错，看起来像SFEP，但是对第三方专有的 libfoo 进行反向工程后发现:

Looks nice and looks like SFEP, but reverse engineering the 3rd party proprietary libfoo reveals:

void foo (int &) {
    if (rand()%2) throw ":P";
}

如果 bar()为 nothrow ，则此参数不成立，因此只能调用 nothrow 函数.

This argument does not hold true if bar() is nothrow and so can only call nothrow functions.

每个可变变量都会增加代码的复杂性，并给代码维护者的大脑能力带来更大负担.这意味着需要更多的代码和更多的状态来进行测试和验证，从而意味着您从维护者的大脑中吸取了更多的状态，进而意味着更少的维护者保留给重要人员的大脑能力.

Every mutable variable increases the complexity of your code and puts a higher burden on the cerebral capacity on your code's maintainer. It means more code and more state to test and verify, in turn means that you suck off more state from the maintainers brain, in turn means less maintainer's brain capacity left for the important stuff.

某些类没有默认构造，如果可能的话，您将不得不编写伪造的代码:

Some classes have no default construction and you would have to write really bogus code, if possible at all:

File mogrify() {
    File f ("/dev/random"); // need bogus init because it requires readable stream
    ...
}

只是为了声明它而已.

这篇关于“缺少返回声明"，但我知道它在那里的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！