6 ms·
Isn't it normal for compilers to just no-op functions that can be proved to have no side effects and no return values?
by sudhirj 11y ago
Isn't it normal for compilers to just no-op functions that can be proved to have no side effects and no return values?
- deleted 11y ago[deleted]
- erubin 11y agothis 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
- Chilinot 11y agoNo, 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.
- cbd1984 11y ago> 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.
- friendzis 11y agoNo, 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.
- cbd1984 10y agoNothing I said was wrong.
- ryandrake 11y agoI 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."