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

Asked 13/2, 2009 at 18:1 Answered 14/2, 2009 at 8:29

Solved c++c c-preprocessor conditional-compilation

Is it possible to do something like this

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

The idea is that if SOMETHING is defined, then calls to foo(...) become comments (or something that doesn't get evaluated or compiled), otherwise it becomes a call to MyFunction.

I've seen __noop used, but I don't believe I can use that.

EDIT(s):

I don't think I can really use a macro here, because MyFunction takes a variable number of arguments.

Also, I'd like to make it so the arguments are NOT evaluated! (So doing something like commenting out the body of MyFunction doesn't really give me what I need, as the arguments will still be evaluated)

Mont answered 13/2, 2009 at 18:1 Comment(4)

See whether your compiler support 'variadic macros'. – Fascicule 13/2, 2009 at 18:14

Why would you want to do this? Maybe there is some other way to get what you need. Because without context, what you want to do seems rather dangerous... – Accrual 13/2, 2009 at 19:6

For compilers that don't support variadic macros is it nice to be able to strip out debug strings and function calls. It saves lots of executable space. – Thremmatology 13/2, 2009 at 19:12

@Accrual Yes, it's to remove trace/debug type statements in release builds. – Mont 13/2, 2009 at 20:54

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

Fascicule answered 13/2, 2009 at 18:1 Comment(16)

Will this work with a variable number of arguments? e.g. foo(a,b,c) – Mont 13/2, 2009 at 18:7

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". – Fascicule 13/2, 2009 at 18:13

@Fascicule If you modify your answer to use a variadic macro, then I think it's exactly what I need :) – Mont 13/2, 2009 at 18:18

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. – Tearle 13/2, 2009 at 18:32

Well, I think I used them recently in the gcc compiler. – Fascicule 13/2, 2009 at 18:39

@Fascicule They work for me. If you change your answer to include them, I'll accept it as being correct. – Mont 13/2, 2009 at 19:5

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. – Anora 13/2, 2009 at 19:28

See my solution for any number of arguments (not including zero). – Thremmatology 13/2, 2009 at 19:31

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?') – Talc 13/2, 2009 at 19:34

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. – Fascicule 13/2, 2009 at 19:46

@Talc ChrisW is exactly right; I'm trying to have a conditional logging type function that only gets used on certain builds. – Mont 13/2, 2009 at 20:6

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. – Anora 14/2, 2009 at 8:53

See: Kernighan & Pike "The Practice of Programming" and also the Goddard Space Flight Center programming standards (software.gsfc.nasa.gov/assetsbytype.cfm?TypeAsset=Standard). – Anora 14/2, 2009 at 8:58

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. – Elodiaelodie 17/2, 2009 at 3:45

@phord I added braces: is that enough to de-confuse? – Fascicule 17/2, 2009 at 3:49

@phord: yup, you're right. do { if (conditional) MyFunction(...); } while (0) -- @ChrisW: no, braces aren't enough because the semi-colon confuses. – Anora 17/2, 2009 at 4:51

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.

Composite answered 13/2, 2009 at 18:4 Comment(2)

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. – Composite 13/2, 2009 at 18:40

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. – Indignant 17/2, 2009 at 5:44

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));

Handgun answered 13/2, 2009 at 19:8 Comment(1)

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. – Beaulieu 13/2, 2009 at 19:23

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

void foo() {}

any calls to foo() should be optimized way.

Patrolman answered 13/2, 2009 at 19:1 Comment(2)

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. – Bathsheba 13/2, 2009 at 19:38

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 ;-) – Patrolman 13/2, 2009 at 20:27

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");

Talc answered 13/2, 2009 at 19:8 Comment(0)

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.

Nonprofessional answered 13/2, 2009 at 22:41 Comment(1)

sizeof has the same problem wrt side effects. – Arieariel 17/2, 2009 at 4:23

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

#define foo //

won't work.

Copyread answered 13/2, 2009 at 19:9 Comment(0)

#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.

Thremmatology answered 13/2, 2009 at 19:12 Comment(0)

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++);

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

Cerise answered 14/2, 2009 at 8:29 Comment(0)

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

Prog answered 13/2, 2009 at 18:4 Comment(0)

What about surrounding each call to myFunction with

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

Junto answered 13/2, 2009 at 20:42 Comment(1)

That gets intolerably clumsy after the second invocation. Don't go down this route. – Anora 17/2, 2009 at 6:5

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags