“missing return statement”, but I know it is there

前端 未结 4 918
面向向阳花
面向向阳花 2021-01-06 19:24

Assume I have the following function:

// Precondition:  foo is \'0\' or \'MAGIC_NUMBER_4711\'
// Returns:       -1 if foo is \'0\'
//                 1 if fo         


        
4条回答
  •  孤街浪徒
    2021-01-06 19:42

    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;
    }
    

    Restructure your code

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

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

    abort()

    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.

    throw

    #include 
    
    if (foo == 0) {
        return bar;
    } else {
        return frob;
    }
    
    throw std::runtime_error ("impossible");
    

    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;
    }
    

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

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

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

    complexity

    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.

    missing default constructor

    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
        ...
    }
    

    That's quite a hack just to get it declared.

提交回复
热议问题