Hacker News Reader

> Isn't it normal for compilers to just no-op functions that can be proved to have no side effects and no return values?

Yes, which is why the volatile qualifier exists: It makes modifying specific variables a side-effect, which then cannot be optimized away.

No, no, no. > 5.1.2.3 > 2 Accessing a volatile object <...> are all side effects.

Yes, modifying is a form of access, but too is a read. Which means one can READ hardware register in a loop and expect it to change without compiler optimizing that out.

Nothing I said was wrong.

I thought this was pretty common knowledge too. I read the article waiting in anticipation for the surprise, and at the end it was basically "I used a macro that is off in release builds, and the compiler did what it was told."

this is a case of the programmer calling his function inside an assert macro, which disappears in the preprocessing step when you compile with -D NDEBUG

No, he/she checked the return value of the function inside an assert macro. But since Visual Studio no-opped the assert in release mode, the compiler found no use in keeping the returned value of the recursive fibonacci code and thus removed the function call altogether.