Are there real life cases when C4930 Visual C++ warning doesn't indicate an error?

Visual C++ can emit C4930 "unused function prototype" warning in the following case:

void SomeUsefulFunction()
{
    SomeResourceLock lock(); //C4930 - unused function prototype
    //code requiring the above lock
}

in the above code the 开发者_如何转开发intention was to construct a stack-allocated RAII object:

void SomeUsefulFunction()
{
    SomeResourceLock lock; //okay
    //code requiring the above lock
}

but since the parentheses were typed variable definition turned into a function prototype and so no RAII object is constructed and there's no "lock" object and code behavior is changed.

Also the warning is only triggered when an unused prototype is inside a function, not at class level. It seems pretty useless to have a function prototype inside a function and not call the prototyped function.

Now I'm tempted to use pragma warning to make Visual C++ treat that particular warning as error.

Are there any real life cases when C4930 doesn't accompany an error?

C++ makes it legal to make function-local declarations, although I've rarely seen this feature used. It's often an error, but for instance, if you really used such a declaration and called the matching function:

int main()
{
    int foo();
    return foo();
}

And then later removed the function call:

int main()
{
    int foo();
    return 0;
}

It would be stupid if suddenly it didn't compile anymore.

So, real-world cases where this does not indicate an error on your end are next to nonexistant, but compilers have to account for imaginary-world issues too, because sometimes the real world gets pretty unreal. Showing a warning seems like a good tradeoff for me: the compiler tells you it's unsure if it's what you really wanted.

Point is, compiler writers can't make it an error, because it's syntactically valid. If you want to treat it as an error in your code, it probably won't cause you any problem.

From your very own link,

C4930 can also occur when the compiler cannot distinguish between a function prototype declaration and a function call.

Of course that alone is probably not sufficient reason to not treat that warning as an error. If the compiler is confused, somebody reading the code might be too, and it should probably be made less ambiguous anyway.

To be honest, I compile with "treat warnings as errors", all warnings, and I think that is a sane decision. While the first time that you enable this feature you will spend some time fixing all warnings before the build is clean, from there on the extra cost of cleaning any introduced warning tends to be small, and they do catch some errors.

As to whether a warning can not be an error in any case, of course. For that particular warning, imagine that you declared a function in the namespace and used it, and later in some refactoring your code no longer needs the function. If you remove the call, the compiler will trigger that warning, and in that particular case nothing is broken. Still, as I already said, I would remove the declaration to have a warning-free build.

void UnusedFunctionPrototype();