I'm working on some C code that does lot's of error reporting and logging when a DEBUG flag is set, which sometimes produces unused variable warnings when compiling with the DEBUG flag not set.
#ifdef DEBUG
#define CHECK(expr) foo(expr)
#else
#define CHECK(expr)
#endif /* DEBUG */
int x = bar(a, b, c); /* bar has to be called for both DEBUG begin defined and undefined */
CHECK(x == SOME_VALUE); /* Produces an "unused variable" warning if DEBUG is undefined
Edit: Just a little reminder (not sure if it is of any consequence): the argument for the CHECK macro is an expression, not a single variable.
For this pattern, what is the best way to get rid of the unused variable warning?
What I tried/though of:
#ifdef DEBUG
int x = bar(a, b, c);
#else
bar(a, b, c);
#endif
CHECK(x == SOME_VALUE);
and then, to avoid writing the call to bar (which is more complicated in the actual call) twice:
#ifdef DEBUG
int x =
#endif
bar(a, b, c);
CHECK(x == SOME_VALUE);
However, I feel like this is not exactly a clean and readable solution. Is there a better way? Note that for performance reasons the CHECK(expr) macro should not produce any code if DEBUG is undefined (EDIT: and thus, expr should not be evaluated).
Is there a more elegant way than the one I outlined above?
#ifdef DEBUG
#define CHECK(x) x
#else
#define CHECK(x) ((void)sizeof((void)(x),0))
#endif
I think this addresses all of the possible issues :
sizeof ensures that the expression is not evaluated at all, so its side-effects don't happen. That is to be consistent with the usual behaviour of debug-only constructs, such as assert.
((x), 0) uses the comma operator to swallow the actual type of (x). This is to prevent VLAs from triggering evaluation.
(void) explicitly ignores the result of (x) and sizeof so no "unused value" warning appears.
If I understood your question correctly, you can do something like
#ifdef DEBUG
.
.
#else
#define CHECK(expr) ((void)(expr))
#endif /* DEBUG */
to get rid of the warning.
With this solution there is no need for an intermediate variable.
#define DEBUG
#define DOCHECK(a) printf("DOCHECK %d\n", a)
#ifndef DEBUG
#define CHECK(a, b) a
#else
#define CHECK(a, b) do {int x = a; DOCHECK(x == b);} while (0)
#endif
int bar(int x, int y)
{
return x+y;
}
int main()
{
CHECK(bar(2,3), 2+3);
return 0;
}
Related
I wanted to know if it was contraindicated to define functions parameters using a macro, knowing they could be variable. Does it break a coding convention ?
example:
#ifdef PREVIOUSLY_DEFINED_MACRO
# define PARAMETERS int a, long b
#else
# define PARAMETERS int a
#endif
void my_func(PARAMETERS)
{
...
}
Thanks !
The code is completely valid but, it's not a good coding practice.
Let's assume the following code snippet:
#ifdef PREV_DEFINED
#define ARGS int x, int y
#else
#define ARGS int x
#endif
#include <stdio.h>
// #define PREV_DEFINED
int func(ARGS) {
// In this context, only 'x' is available
// set by the macro
return (x + y); // ERROR, 'y' is undefined
// You need to make a different code, specifically for
// #ifdef PREV_DEFINED and #else
}
To solve this, you need to make two or more different functions within those #ifdef and #endif flags whose usage is controlled by the PREV_DEFINED macro that depends on how many parameters could be variadic. Eventually, this will make the code look worse.
I have some macros that are defined based on compiler flags. I'm trying to decide whether I would rather have the macro defined as (void)0 or have it undefined and cause a compile time error.
i.e.
#ifdef DEBUG
#define PRINTF(...) printf(__VA_ARGS__)
#else
#define PRINTF(...) (void)0
#endif
int main(void) {
...
PRINTF("something");
...
}
vs.
#ifdef DEBUG
#define PRINTF(...) printf(__VA_ARGS__)
#endif
int main(void) {
...
#ifdef DEBUG
PRINTF("something");
#endif
...
}
I'm not sure which technique I prefer. On one hand wrapping every PRINTF statement with #ifdef's would be ugly. On the other hand it would be nice to know at compile time if I've called a function that doesn't really work in the context.
I think the deciding factor will be whether or not having the (void)0 macros is going to affect the size of the executable.
When the code is compiled, what happens to the (void)0's? If PRINTF is defined as (void)0, does that mean the executable is going to contain some sort of (void)0 instruction or will it be completely ignored?
(void) 0;
is an expression statement with no side-effect. Any sane implementation will optimize this statement out (what else an implementation could do with such a statement?).
Having (void) 0 as a macro definition is endorsed by the C Standard as it appears in (C11) 7.2p1 for assert macro definition if NDEBUG is defined:
#define assert(ignore) ((void)0)
Note that defining:
#define PRINTF(...) (void)0
instead of
#define PRINTF(...)
has an advantage. In the first case, you have an expression (like a function that returns no value) and so it is usable for example in a comma expression or in a conditional expression.
For example:
// Comma expression
printf("test"), PRINTF("Hi Dennis");
// Conditional expression
test-expr ? perror("Hello") : PRINTF("world");
This two expression statements are only valid with the former PRINTF definition (with (void) 0).
It'll be completely ignored, you can confirm this by looking at the assembly output (gcc -S will generate file.s, the asm output), compare with and without the (void)0 line and see that it is completely the same.
A half way decent compiler will optimise away dead (unreachable) code, so you can:
#ifdef DEBUG
#define PRINTF(...) if (1) { printf(__VA_ARGS__) ; }
#else
#define PRINTF(...) if (0) { printf(__VA_ARGS__) ; }
#endif
which has the big advantage of allowing the compiler to check the debug code, no matter whether you are working with/without your DEBUG turned on -- which reduces the risk of ending up with painful teeth marks in your backside.
I have the following code, and while compiling it with gcc-4.6 I get warning:
warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
#if defined (_DEBUG_)
#define ASSERT assert
#else /* _DEBUG_ */
#define ASSERT( __exp__ )
#endif
static inline void cl_plock(cl_plock_t * const p_lock)
{
status_t status;
ASSERT(p_lock);
ASSERT(p_lock->state == INITIALIZED);
status = pthread_rwlock_unlock(&p_lock->lock);
ASSERT(status == 0);
}
When _DEBUG_
flag isn't set I get the warning.
Any ideas how can I workaround this warning?
You can change your ASSERT macro to:
#if defined (_DEBUG_)
#define ASSERT assert
#else /* _DEBUG_ */
#define ASSERT( exp ) ((void)(exp))
#endif
If the expression has no sideeffects, then it should still be optimised out, but it should also suppress the warning (if the expression does have side-effects, then you would get different results in debug and non-debug builds, which you don't want either!).
The compiler option to turn off unused variable warnings is -Wno-unused.
To get the same effect on a more granular level you can use diagnostic pragmas like this:
int main()
{
#pragma GCC diagnostic ignored "-Wunused-variable"
int a;
#pragma GCC diagnostic pop
// -Wunused-variable is on again
return 0;
}
This is, of course, not portable but you can use something similar for VS.
You could surround the variable declaration of status with a #ifdef clause.
#ifdef _DEBUG_
status_t status
#endif
EDIT: You have to surround the call also:
#ifdef _DEBUG_
status = pthread_rwlock_unlock(&p_lock->lock);
#else
pthread_rwlock_unlock(&p_lock->lock);
#endif
or you can switch off the error message.
I'm trying to do a debug system but it seems not to work.
What I wanted to accomplish is something like this:
#ifndef DEBUG
#define printd //
#else
#define printd printf
#endif
Is there a way to do that? I have lots of debug messages and I won't like to do:
if (DEBUG)
printf(...)
code
if (DEBUG)
printf(...)
...
No, you can't. Comments are removed from the code before any processing of preprocessing directives begin. For this reason you can't include comment into a macro.
Also, any attempts to "form" a comment later by using any macro trickery are not guaranteed to work. The compiler is not required to recognize "late" comments as comments.
The best way to implement what you want is to use macros with variable arguments in C99 (or, maybe, using the compiler extensions).
A common trick is to do this:
#ifdef DEBUG
#define OUTPUT(x) printf x
#else
#define OUTPUT(x)
#endif
#include <stdio.h>
int main(void)
{
OUTPUT(("%s line %i\n", __FILE__, __LINE__));
return 0;
}
This way you have the whole power of printf() available to you, but you have to put up with the double brackets to make the macro work.
The point of the double brackets is this: you need one set to indicate that it's a macro call, but you can't have an indeterminate number of arguments in a macro in C89. However, by putting the arguments in their own set of brackets they get interpreted as a single argument. When the macro is expanded when DEBUG is defined, the replacement text is the word printf followed by the singl argument, which is actually several items in brackets. The brackets then get interpreted as the brackets needed in the printf function call, so it all works out.
С99 way:
#ifdef DEBUG
#define printd(...) printf(__VA_ARGS__)
#else
#define printd(...)
#endif
Well, this one doesn't require C99 but assumes compiler has optimization turned on for release version:
#ifdef DEBUG
#define printd printf
#else
#define printd if (1) {} else printf
#endif
On some compilers (including MS VS2010) this will work,
#define CMT / ## /
but no grantees for all compilers.
You can put all your debug call in a function, let call it printf_debug and put the DEBUG inside this function.
The compiler will optimize the empty function.
The standard way is to use
#ifndef DEBUG
#define printd(fmt, ...) do { } while(0)
#else
#define printd(fmt, ...) printf(fmt, __VA_ARGS__)
#endif
That way, when you add a semi-colon on the end, it does what you want.
As there is no operation the compiler will compile out the "do...while"
Untested:
Edit: Tested, using it by myself by now :)
#define DEBUG 1
#define printd(fmt,...) if(DEBUG)printf(fmt, __VA_ARGS__)
requires you to not only define DEBUG but also give it a non-zer0 value.
Appendix:
Also works well with std::cout
In C++17 I like to use constexpr for something like this
#ifndef NDEBUG
constexpr bool DEBUG = true;
#else
constexpr bool DEBUG = false;
#endif
Then you can do
if constexpr (DEBUG) /* debug code */
The caveats are that, unlike a preprocessor macro, you are limited in scope. You can neither declare variables in one debug conditional that are accessible from another, nor can they be used at outside function scopes.
You can take advantage of if. For example,
#ifdef debug
#define printd printf
#else
#define printd if (false) printf
#endif
Compiler will remove these unreachable code if you set a optimization flag like -O2. This method also useful for std::cout.
As noted by McKay, you will run into problems if you simply try to replace printd with //. Instead, you could use variadric macros to replace printd with a function that does nothing as in the following.
#ifndef DEBUG
#define printd(...) do_nothing()
#else
#define printd(...) printf(__VA_ARGS__)
#endif
void do_nothing() { ; }
Using a debugger like GDB might help too, but sometimes a quick printf is enough.
I use this construct a lot:
#define DEBUG 1
#if DEBUG
#if PROG1
#define DEBUGSTR(msg...) { printf("P1: "); printf( msg); }
#else
#define DEBUGSTR(msg...) { printf("P2: "); printf( msg); }
#endif
#else
#define DEBUGSTR(msg...) ((void) 0)
#endif
This way I can tell in my console which program is giving which error message... also, I can search easily for my error messages...
Personally, I don't like #defining just part of an expression...
It's been done. I don't recommend it. No time to test but the mechanism is kind of like this:
#define printd_CAT(x) x ## x
#ifndef DEBUG
#define printd printd_CAT(/)
#else
#define printd printf
#endif
This works if your compiler processes // comments in the compiler itself (there's no guarantee like the ANSI guarantee that there are two passes for /* comments).
This question already has answers here:
#define macro for debug printing in C?
(14 answers)
Closed 5 years ago.
From what I understand assert is a macro in C and supposedly if you use it at compile time but leave it disabled then there won't be overhead (which might not be correct I don't know).
The problem for me is that what I'd like to do is get all the variables passed to my function and print out that output, but only if I want debugging enabled. Here is what I have so far:
int exampleFunction (int a, int b)
{
#ifdef debugmode
printf("a = %i, b = %i", a, b);
#endif
}
I'm wondering if there is any easier (and less ugly) method for doing something like this. xdebug for php has this feature and I've found is saves me an enormous amount of time when debugging so i want to do it for each function.
Thanks
try this:
#ifdef debugmode
#define DEBUG(cmd) cmd
#else
#define DEBUG(cmd)
#endif
DEBUG(printf("a = %i, b = %i", a, b));
now, if you have debugmode defined, you get your print statement. otherwise, it never shows up in the binary.
Using GCC, I really enjoy to add, per file:
#if 0
#define TRACE(pattern,args...) fprintf(stderr,"%s:%s/%u" pattern "\n",__FILE__,__FUNCTION__,__LINE__,##args)
#else
#define TRACE(dummy,args...)
#endif
and then in the code:
i++;
TRACE("i=%d",i);
i will be printed only when I activate the TRACE() macro in the top of the file. Works really great, plus it prints the source file, line and function it occurred.
if (MY_DEBUG_DEFINE) {
do_debug_stuff();
}
Any half decent compiler would optimize the block away. Note you need to define MY_DEBUG_DEFINE as a boolean (ie 0 or not 0).
#define MY_DEBUG_DEFINE defined(NDEBUG)
If you happen to compile with maximum warning level, this trick avoids unreferenced argument.
Workaround to get vararg with preprocessors that don't support it
#define DEBUG
#ifdef DEBUG
#define trace(args) printf args
#else
#define trace(args)
#endif
int dostuff(int value)
{
trace(("%d", value));
}
You can define PRINTF_IF_DEBUGGING as
#ifndef NDEBUG
#define PRINTF_IF_DEBUGGING(X) printf(X)
#else
#define PRINTF_IF_DEBUGGING(X)
#endif
This will centralize the #ifdefs in only one place.
Well, the problem with the PRINT_DEBUG type macros as given here, is that they only allow one parameter. For a proper printf() we'll need several, but C macros don't (presently) allow variable arguments.
So, to pull this off, we've got to get creative.
#ifdef debugmode
#define PRINTF printf
#else
#define PRINTF 1 ? NULL : printf
#endif
Then when you write PRINTF("a = %i, b = %i", a, b);, in non-debug mode, it will be renders as (effectively):
if (true) NULL;
else printf("a = %i, b = %i", a, b);
The compiler is happy, but the printf is never execute, and if the compiler if bright (i.e, any modern C compiler), the code for the printf() will never be generated, as the compiler will recognize that path can never be taken.
Note, however, that the parameters will still be evaluated, so if they have any side effects (i.e, ++x or a function call), they code may be generated (but not executed)
I would also print some other C preprocessor flags that can help you track problems down
printf("%s:%d {a=%i, b=%i}\n", __FILE__, __LINE__, a, b);