C++ Macros with variable number of arguments

[Update 2022 Feb]

If you ask any C expert, <stdarg.h> is actually to be avoided at all costs. Yes, the key problem is that the API of such a function, imposed on the user, has to “tell” explicitly the length of the arguments list, or use a sentinel for the last argument or have special logic like printf(const char *, ...) simply peeking into the first argument to decide on the end of operations.

Very clean and simple design is to combine standard variadic macro with callback

Here is the one I prepared earlier.

#include <stdarg.h> not required. That macro simply prepares two arguments for the callback and then uses the lot. And of course, Godbolt is ready for you.

[The original article 2018 Oct]

Dealing with a variable number of arguments is pretty easy in C++. Alas in real life, you will need to dive into C, from time to time. And possibly meet C/C++ macros with a variable number of arguments, or even worse sounding “Variadic Macro’s“. But why would anybody need any of this?

Like C++ is not “hard enough” already, one might exclaim? Well, standard C++ is not that hard.  But to learn anything properly, good examples are priceless. Here is perhaps one good example aka “use case” where one can deploy variadic macros.

(In case you are in a hurry, Godbolt is here)

Sooner or later you realize your C code will be full of malloc() calls. It is extremely important to get into the habit of free() ing, anything that should be freed. Just free-free-free, as much as you can. Being “foolishly” involved with standard C too, I  have developed my little function to “free in bulk”.   Next is the why and the test code.

First here is some heap-allocated data, that requires a lot of free() calls afterwards.

In C there are no destructors, so you better be sure you have cleaned up after yourself. A good example is code like above, with a mandatory, long, and tedious sequence of calls to standard function free() that has to come after it :

This is not very nice. And more importantly, that is a bit tiresome. So, I have developed a variadic function with a signature like this:

And, I have developed a variadic macro with a normal name to use this useful function:

That syntax is simple. As is the usage standard inbuilt predefined __VA_ARGS__ that will become arguments list expanded. Now I can ease (a bit), a burden of repeated free calls:

But. Dear CLANG (aka LVVM) in its standard C reincarnation screams at me now:

Hmm, casting each argument will be obviously as tedious as typing separate free calls, if not even  more tedious:

Clearly not acceptable.  So, I have tweaked my variadic macro:

This macro now expands into:

Just the first argument is cast as requested.  And that pacifies the compiler since the remaining args types are not checked before they are used inside the variadic function.

And (lo and behold) there is no warning and all is dandy (in the land of candy).

But what about this annoying little comment we keep on dragging around?

/* do not ever forget NULL as the last argument! */

Standard C, variadic functions implementation is based on what is available in <stdarg.h >. There is no mechanism in there to tell us which is the last argument in standard C variadic functions.  In this case, we need to use the concept of the “last argument sentinel”. The last argument is therefore a special value (sentinel) that signals the list of arguments is finished. And since the type of every argument is void * , NULL is the only logical choice.

Fine. I then do the last and final version of my FREE variadic macro, by simply adding the NULL argument in the call:

A function is implemented to stop if the argument is NULL. And this is one very good example of why sometimes we need variadic macros and how to use them. The call to MULTIFREE looks now pretty normal, and a good replacement for repeated calls to free().

No casting and no last argument sentinel necessary.

I am sure you can extrapolate this to your various use cases, with variadic functions in standard C.

Yes, we already said: the code is here. It does not exactly match this post. It is better.

%d bloggers like this: