Why is (void) 0 a no operation in C and C++?

馋奶兔 提交于 2019-11-27 17:23:29
Alexander Gessler

(void)0 (+;) is a valid, but 'does-nothing' C++ expression, that's everything. It doesn't translate to the no-op instruction of the target architecture, it's just an empty statement as placeholder whenever the language expects a complete statement (for example as target for a jump label, or in the body of an if clause).

EDIT: (updated based on Chris Lutz's comment)

It should be noted that when used as a macro, say

#define noop ((void)0)

the (void) prevents it from being accidentally used as a value like

int x = noop;

For the above expression the compiler will rightly flag it as an invalid operation. GCC spits error: void value not ignored as it ought to be and VC++ barks 'void' illegal with all types.

Any expression that doesn't have any side-effects can be treated as a no-op by the compiler, which dosn't have to generate any code for it (though it may). It so happens that casting and then not using the result of the cast is easy for the compiler (and humans) to see as not having side-effects.

I think you are talking about glibc, not glib, and the macro in question is the assert macro:

In glibc's <assert.h>, with NDEBUG (no debugging) defined, assert is defined as:

#ifdef NDEBUG
#if defined __cplusplus && __GNUC_PREREQ (2,95)
# define __ASSERT_VOID_CAST static_cast<void>
#else
# define __ASSERT_VOID_CAST (void)
#endif
# define assert(expr)           (__ASSERT_VOID_CAST (0))
#else
/* more code */
#endif

which basically means assert(whatever); is equivalent to ((void)(0));, and does nothing.

From the C89 standard (section 4.2):

The header <assert.h> defines the assert macro and refers to another macro,

NDEBUG

which is not defined by <assert.h>. If NDEBUG is defined as a macro name at the point in the source file where <assert.h> is included, the assert macro is defined simply as

#define assert(ignore) ((void)0)

I don't think defining a debug print macro to be equal to (void)0 makes much sense. Can you show us where that is done?

Even if so, why type cast it to void? Also, in case of the #define dbgprintf (void) 0, when it's called like dbgprintf("Hello World!"); -> (void) 0("Hello World!"); - what does it mean? – legends2k

Macros replace your code with something else, so if you #defined dbgprint (that accepts x) as

void (0)

then no rewriting of X will occur in replacement, so dbgprintf("Helloworld") will not be converted to (void) 0("Hello world"), but to (void) 0; - not only macro name dbgprint is replaced by (void) 0, but the whole call dbgprintf("...")

On Windows, I try some code like this in Main.cpp:

#include <iostream>
#define TRACE ((void)0)
int main() {
  TRACE("joke");
  std::cout << "ok" << std::endl;
  return 0;
}

Then, I build the Release version exe file with Main.i output. In Main.i file, the TRACE macro was replaced to:((void)0)("joke"), and visual studio give an warning:"warning C4353: nonstandard extension used: constant 0 as function expression. Use '__noop' function intrinsic instead". Run the exe file, console print out "ok" characters. So I think all is clear: the definition of macro TRACE[#define TRACE ((void)0)] is illegal according to c++ syntax, but c++ compiler of visual studio supports this behavior as a compiler extension. So my conclusion is: [#define TRACE ((void)0)] is illegal c++ statement, and you at best DO NOT use this. But [#define TRACE(x) ((void)0)] is legal statement. That's all.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!