# Why does this compile? C++

This topic is 4326 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

This really messed me up in my project. The below is an example.
int x() {}
int main() { int y = x(); }



##### Share on other sites
It compiles because the standard doesn't say it's an error and compilers need to compile code which isn't erroneous in order to be standards-compliant. It's also occasionally useful:

int a(){    if(b) {        return 3;    } else {        exit(-1);    }}

All modern compilers will recognize code where not all the paths return a value, and warn you about it. Programmers who ignore warnings--or lower the warning level--do so at their own peril.

##### Share on other sites
Perhaps your compiler is broken! Good luck!

##### Share on other sites
It only warns if I use "-Wall" is this normal or should the compiler be warning me by default?

When a function returns a class, will that class be properly constructed (with a default constructor) or will the returned object be undefined?

##### Share on other sites
Quote:
 Original post by BoderIt only warns if I use "-Wall" is this normal or should the compiler be warning me by default?

Warning levels (which is what -Wall effectively is) are compiler-dependent. There is nothing which says that this code must produce a warning at all.

Anyway, I recommend always using -Wall.

##### Share on other sites
Quote:
 Original post by BoderIt only warns if I use "-Wall" is this normal or should the compiler be warning me by default?

You should be using -Wall all the time.

##### Share on other sites
What about my second question, is the return value undefined?

Yep.

##### Share on other sites
Quote:
 Original post by SneftelIt compiles because the standard doesn't say it's an error and compilers need to compile code which isn't erroneous in order to be standards-compliant. It's also occasionally useful:int a(){ if(b) { return 3; } else { exit(-1); }}All modern compilers will recognize code where not all the paths return a value, and warn you about it. Programmers who ignore warnings--or lower the warning level--do so at their own peril.

To avoid this warning, you can do this:

int a(){    if(!b) {        exit(-1);    }    return 3;}

Any "non return" exits before end of function.

##### Share on other sites
Yes. That can often require ordering your logic in an unintuitive fashion, though. Luckily, compilers tend to recognize functions like exec() and exit() as "special", and don't emit the warning. Of course, you can always just put a "return 0" right afterwards.

##### Share on other sites
ha ha ha C++ is weird,
i've always wondered why this compiles too (the object isn't even
created yet though you can pass it as an argument to the copy
constructor):

class x {};
x obj(obj);

##### Share on other sites
On that code, obj is already declared, but not initialized. In my opinion, it shouldn't compile, as it doesn't get contructed. You will make a copy construction of an uninitialized object.

##### Share on other sites
Quote:
 Original post by KalazartOn that code, obj is already declared, but not initialized. In my opinion, it shouldn't compile, as it doesn't get contructed. You will make a copy construction of an uninitialized object.

When writing a compiler, especially one like C/C++, it's somewhat difficult to do analysis of code/data flow. Therefore it's often "piggybacked" onto the optimization step, which does the right analysis anyway.

So you'll often find compilers that emit different warnings depending on whether optimization is on or off, since if it's off the compiler is not always able to properly determine what your code does. I believe GCC does this sometimes, though I don't remember.