ansaurus

Question

Use #ifdefs and #define to optionally turn a function call into a comment

Answer 1

+17 A:

Try this:

#ifdef SOMETHING
#define foo(x)
#else
#define foo(x) MyFunction(x)
#endif

If your function has several arguments, then:

#ifdef SOMETHING
#define foo(x,y,z)
#else
#define foo(x,y,z) MyFunction(x,y,z)
#endif

If your function has a variable number of arguments, then your compiler may support so-called "variadic macros", like this:

#ifdef SOMETHING
#define foo(...)
#else
#define foo(...) MyFunction(__VA_ARGS__)
#endif

The reason which I've seen this kind of thing used in practice is to get rid of logging functions from a release build. However, see also http://stackoverflow.com/questions/420343/separate-debug-and-release-builds in which people question whether you should even have different builds.

Alternatively, instead of redefining the function call as nothing, Jonathan's comment to this answer suggested doing something like the following:

#ifdef SOMETHING
#define foo(...) do { if (false) MyFunction(__VA_ARGS__) } while (0)
#else
#define foo(...) do { if (true) MyFunction(__VA_ARGS__) } while (0)
#endif

The reasoning for doing this is so that the function call is always compiled (so it won't be left with gratuitous errors like references to deleted variables), but only called when needed: see Kernighan & Pike The Practice of Programming and also the Goddard Space Flight Center programming standards.

From a debug.h file (originating from 1990, and therefore not using __VA_ARGS__):

/*
** Usage:  TRACE((level, fmt, ...))
** "level" is the debugging level which must be operational for the output
** to appear. "fmt" is a printf format string. "..." is whatever extra
** arguments fmt requires (possibly nothing).
** The non-debug macro means that the code is validated but never called.
** -- See chapter 8 of 'The Practice of Programming', by Kernighan and Pike.
*/
#ifdef DEBUG
#define TRACE(x)    db_print x
#else
#define TRACE(x)    do { if (0) db_print x; } while (0)
#endif /* DEBUG */

With C99, there's no longer a need for the double parentheses trick. New code should not use it unless C89 compatibility is an issue.

ChrisW 2009-02-13 18:04:29

Will this work with a variable number of arguments? e.g. foo(a,b,c)

Daniel LeCheminant 2009-02-13 18:07:33

It will work with a greater-than-one-but-fixed number of arguments. For a variable number of arguments, Google and/or check your compiler documentation for so-called "variadic macros".

ChrisW 2009-02-13 18:13:42

@ChrisW If you modify your answer to use a variadic macro, then I _think_ it's exactly what I need :)

Daniel LeCheminant 2009-02-13 18:18:21

Variadic macros are in the latest C standard. I'm not sure about C++0x, can't get the latest draft to download right now, and they aren't listed in the Wikipedia article, but they'll probably be available.

David Thornley 2009-02-13 18:32:13

Well, I think I used them recently in the gcc compiler.

ChrisW 2009-02-13 18:39:48

@ChrisW They work for me. If you change your answer to include them, I'll accept it as being correct.

Daniel LeCheminant 2009-02-13 19:05:27

You should normally define the non-function call as something like ((void)0) to avoid compilation problems. Having said that, I'm not coming up with a scenario where it actually matters - outside of an expression. And in an expression, you probably wouldn't use the void cast.

Jonathan Leffler 2009-02-13 19:28:32

See my solution for any number of arguments (not including zero).

MSN 2009-02-13 19:31:17

A problem I see is that for each function you want to conditionally execute, a new macro has to be defined. Enclosing the whole function call in a macro will work with any number of functions and is more explicit, ie less likely to cause confusion ('Where the hell did my function call go?')

Christoph 2009-02-13 19:34:23

added a paragraph to say what this is used for and to reference a question that wonders whether that's always such a good idea.

ChrisW 2009-02-13 19:46:20

@Christoph ChrisW is exactly right; I'm trying to have a conditional logging type function that only gets used on certain builds.

Daniel LeCheminant 2009-02-13 20:06:51

@xvb: I use those myself - I'll update my answer accordingly...

Christoph 2009-02-13 20:27:07

For conditional logging, use: if (ConditionalLoggingEnabled) { MyFunction(...); } where ConditionalLoggingEnabled is a compile time constant: 0 or 1. The function call is always compiled (so it won't be left with gratuitous errors like references to deleted variables), but only called when needed.

Jonathan Leffler 2009-02-14 08:53:38

Jonathan Leffler 2009-02-14 08:58:41

Thanks Jonathan, I'll add that.

ChrisW 2009-02-14 15:53:20

Ack! Don't use "if (ConditionalLoggingEnabled) { MyFunction(...); }" without giving serious consideration to the "else". For example, "if (somevar) TRACE(somevar); else TRACE(somevar+1);" gets hopelessly confused by the ambiguous else once "TRACE" expands to an extra if-clause.

phord 2009-02-17 03:45:35

@phord I added braces: is that enough to de-confuse?

ChrisW 2009-02-17 03:49:37

@phord: yup, you're right. do { if (conditional) MyFunction(...); } while (0) -- @ChrisW: no, braces aren't enough because the semi-colon confuses.

Jonathan Leffler 2009-02-17 04:51:02

Answer 2

A:

If I remember correctly, you should be able to #define your macro to "nothing" and that will cause the compiler to ignore that call

#define foo()

foo();    // this will be ignored

Miky Dinescu 2009-02-13 18:04:55

Answer 3

+4 A:

Maybe an easier way to do this would be to conditionally omit the body of the function?

void MyFunction() {
#ifndef SOMETHING
    <body of function>
#endif
}

Unless you specifically don't want a function call to be made at all, this seems like a clean way to achieve your goal.

MattK 2009-02-13 18:04:57

But the arguments will still be evaluated...

Daniel LeCheminant 2009-02-13 18:08:13

True. I think that if you don't want the arguments evaluated, then you may have to go as far as #ifdefing out all the calls. The "#define foo(x)" solution will also evaluate your arguments on most compilers.

MattK 2009-02-13 18:40:30

Not only the arguments are evaluated, but the data for them is included which is not very nice if the function is a logging function and arguments are huge strings disclosing the functioning of your application.

sharptooth 2009-02-17 05:44:56

Answer 4

+1 A:

If, in the case you don't want foo called, you define it as:

void foo() {}

any calls to foo() should be optimized way.

Ferruccio 2009-02-13 19:01:47

I think you should probably declare it inline as well to guarantee it gets optimized away. It should support varargs too, so I think this is probably the best solution.

rmeador 2009-02-13 19:38:56

It depends on the compiler. I've seen VC++ optimize away functions with code in them when it could determine that they had no side effects. Very frustrating when you're trying to do benchmarks ;-)

Ferruccio 2009-02-13 20:27:02

Answer 5

+1 A:

What about something along these lines:

#ifdef NDEBUG
#define DEBUG(STATEMENT) ((void)0)
#else
#define DEBUG(STATEMENT) (STATEMENT)
#endif

You would use it like this to log debugging messages:

DEBUG(puts("compile with -DNDEBUG and I'm gone"));

A non-generic version for formatted output with additional debugging information using C99 variadic macros and the __func__ identifier could look like this:

#ifdef NDEBUG
#define Dprintf(FORMAT, ...) ((void)0)
#define Dputs(MSG) ((void)0)
#else
#define Dprintf(FORMAT, ...) \
    fprintf(stderr, "%s() in %s, line %i: " FORMAT "\n", \
        __func__, __FILE__, __LINE__, __VA_ARGS__)
#define Dputs(MSG) Dprintf("%s", MSG)
#endif

Here's how you'd use these macros:

Dprintf("count = %i", count);
Dputs("checkpoint passed");

Christoph 2009-02-13 19:08:18

Answer 6

+3 A:

Unfortunately the current C++ version doesn't support variadic macros.

However, you can do this:

#ifdef SOMETHING
#define foo
#else
#define foo(args) MyFunction args
#endif

// you call it with double parens:
foo((a, b, c));

2009-02-13 19:08:34

I do this with debug logging functions so that (a) they vanish entirely in production builds, and (b) I can pass in a format string and any number of args.

Graeme Perrow 2009-02-13 19:23:32

Answer 7

+1 A:

No, the C and C++ Standards say you cannot #define something to be a comment, so

#define foo //

won't work.

anon 2009-02-13 19:09:14

Answer 8

+1 A:

#ifdef SOMETHING
#define foo sizeof
#else
#define foo MyFunction
#endif

I'm assuming that foo is a printf style function? Anyways, this won't work with a zero parameter function, but if that were the case, you would already know what to do. If you really want to be anal you can use (void)sizeof but that's probably unnecessary.

MSN 2009-02-13 19:12:08

Answer 9

A:

What about surrounding each call to myFunction with

#ifdef SOMETHING
myFunction(...);
#endif

?

Brian Postow 2009-02-13 20:42:30

That gets intolerably clumsy after the second invocation. Don't go down this route.

Jonathan Leffler 2009-02-17 06:05:29

Answer 10

+1 A:

Likely, you don't want to do the simple "code removal" as suggested, because your callers will be expecting the side effects of the arguments to happen. Here are some troublesome caller snippets that should get you thinking:

// pre/post increment inside method call:
MyFunction(i++); 

// Function call (with side effects) used as method argument: 
MyFunction( StoreNewUsernameIntoDatabase(username) );

If you were to disable MyFunction by simply saying:

#define MyFunction(x)

then the side effects that the callers were expecting would go away, and their code would break, and be quite difficult to debug. I like the "sizeof" suggestion above, and I also like the suggestion to just disable the body of MyFunction() via #ifdef's, although that means that all callers get the same version of MyFunction(). From your problem statement, I presume that's not actually what you want.

If you really need to disable MyFunction() via preprocessor defines on a per-source-file basis, then I'd do it like this:

#ifdef SOMETHING 
#define MyFunction(x) NoOp_MyFunction(x) 

int NoOp_MyFunction(x) { } 
#endif

You could even include the implementation of NoOp_MyFunction() inside the source & headers for MyFunction(). You also have the flexibility to add extra logging or debugging information in NoOp_MyFunction() as well.

slacy 2009-02-13 22:41:17

`sizeof` has the same problem wrt side effects.

Logan Capaldo 2009-02-17 04:23:14

Answer 11

+1 A:

I'm a little reluctant to post this answer because it's use of macro hackery can become the source of problems. However - if the calls to the function you want to have disappear are always used alone in a statement (ie., they are never part of a larger expression), then something like the following could work (and it handles varargs):

#ifdef SOMETHING
#define foo (1) ? ((void) 0) : (void)
#else
#define foo MyFunction
#endif

So if you have the line of code:

foo( "this is a %s - a++ is %d\n", "test", a++);

it will end up after the preprocessing step as either:

MyFunction( "this is a %s - a++ is %d\n", "test", a++);

or

(1) ? ((void) 0) : (void)( "this is a %s - a++ is %d\n", "test", a++);

which turns the pseudo-function's parameter list into a bunch of expressions separated by the comma operator that will never be evaluated, since the conditional always returns the ((void) 0) result.

A variant of this is something close to what ChriSW and Jonathan Leffler suggested:

#ifdef SOMETHING
#define foo if (0) MyFunction
#else
#define foo if (1) MyFunction
#endif

This is slightly different in that it does not require the compiler to support variadic macros (__VA_ARGS__).

I think this can be useful for eliminating debug trace function calls which are generally never combined into a larger expression, but beyond that I think it's a dangerous technique.

Note the potential for problems - especially if the parameters in the call produce side-effects (this is a general problem with macros - not just this hack). In the example, the a++ will be evaluated only if SOMETHING is defined in the build, otherwise it's not. So if code after the call depends on the value of a to be incremented, one of the builds has a bug.

Michael Burr 2009-02-14 08:29:33

ansaurus

tags:

views:

answers:

Use #ifdefs and #define to optionally turn a function call into a comment

related questions