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

C++CCompiler Construction

C++ Problem Overview


I have seen debug printfs in glibc which internally is defined as (void) 0, if NDEBUG is defined. Likewise the __noop for Visual C++ compiler is there too. The former works on both GCC and VC++ compilers, while the latter only on VC++. Now we all know that both the above statements will be treated as no operation and no respective code will be generated; but here's where I've a doubt.

In case of __noop, MSDN says that it's a intrinsic function provided by the compiler. Coming to (void) 0 ~ Why is it interpreted by the compilers as no op? Is it a tricky usage of the C language or does the standard say something about it explicity? Or even that is something to do with the compiler implementation?

C++ Solutions


Solution 1 - C++

(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).

From 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 in 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.

Solution 2 - C++

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.

Solution 3 - C++

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?

Solution 4 - C++

> 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?

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("...")

Solution 5 - C++

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionlegends2kView Question on Stackoverflow
Solution 1 - C++Alexander GesslerView Answer on Stackoverflow
Solution 2 - C++anonView Answer on Stackoverflow
Solution 3 - C++Alok SinghalView Answer on Stackoverflow
Solution 4 - C++Darko MaksimovicView Answer on Stackoverflow
Solution 5 - C++baojing.zhouView Answer on Stackoverflow