Welcome to another Friday Q&A, where all references are strong and all values are above average. This week I'm going to talk about how to write macros and functions that take variable arguments in C, as suggested by Damien Sorresso.

Macros
Writing a vararg macro is pretty simple in principle. Note that unlike functions, vararg macros are new as of C99, so they won't work with earlier dialects. You create one by putting ... at the end of the macro's argument list, like so:

    #define vararg_macro(a, b, c, ...)

Here's an example of a debug logging macro using this technique:

    #define DEBUG_LOG(...) do { \
        if(gDebugLoggingEnabled) { \
            fprintf(stderr, "Debug log:" __VA_ARGS__); \
            fprintf(stderr, "\n") \
        } \
    } while(0)

    if(!condition)
        DEBUG_LOG("condition was false!");
    else
        do_something_important();

Now let's say we wanted to add logging of the file name and line number where the log is, using the __FILE__ and __LINE__ macros. We could do this by adding a third fprintf line, but imagine we want to combine it into the first line instead. This is easy enough to do:

    #define DEBUG_LOG(fmt, ...) do { \
        if(gDebugLoggingEnabled) \
            fprintf(stderr, "Debug log, %s:%d: " fmt "\n", __FILE__, __LINE__, __VA_ARGS__); \
    } while(0)

The easiest solution to this is to take advantage of a gcc-specific extension. Putting ## in between the comma and the __VA_ARGS__ will remove the comma when __VA_ARGS__ is empty:

    #define DEBUG_LOG(fmt, ...) do { \
        if(gDebugLoggingEnabled) \
            fprintf(stderr, "Debug log, %s:%d: " fmt "\n", __FILE__, __LINE__, ## __VA_ARGS__); \
    } while(0)

Functions
Vararg functions aren't that much harder. The declaration is pretty much the same as for a macro: put ... at the end of the argument list. One important difference can be seen here: the ... must not be the only parameter the function takes. In other words, a vararg function must take at least one fixed parameter.

In the body of the function, you'll want to make sure to do #include to get the appropriate declarations, then you can use some simple functions to work with the argument list. The va_list type describes a variable argument list. Then you call va_start on it to initialize it. To do your actual work, call va_arg in a loop to pop arguments, and when you're all done you call va_end to terminate processing.

Note that these are the only three operations supported. It's not possible to query the argument list for length, for type, or anything else like that. You must take care of these things yourself by arranging a convention with the caller.

Let's write a quick example. Imagine that for some reason you find yourself frequently needing to post several NSNotifications at a time. To cut down on the work required, we can write a vararg function that takes a number of notifications as the parameters. This is what the declaration will look like:

    void PostNotifications(id obj, NSString *firstNotificationName, ... /* terminate with nil */)

Next, we'll set up the va_list:

    {
        va_list args;
        va_start(args, firstNotificationName);

Next, we'll run a loop to post the notifications:

        NSString *notificationName = firstNotificationName;
        while(notificationName)
        {
            [[NSNotificationCenter defaultCenter] postNotificationName:notificationName object:obj];
            notificationName = va_arg(args, NSString *);
        }

        va_end(args);
    }

    PostNotifications(self, FirstNotificationName, SecondNotificationName, ThirdNotificationName, nil);

This is kind of fragile, because you'll crash if the caller forgets to terminate the list, and anything could happen if he passes in something of the wrong type (like a float) by accident, but that's just how vararg functions work in C.

Conclusion
That wraps up this week's Friday Q&A. Vararg macros and functions are a little strange but they can be handy, and once you know the basics they're not too hard to make at all.

Come back next week for another exciting edition. As always, Friday Q&A is driven by you, the reader. If you have any suggestions for a future topic of discussion, post it in the comments or e-mail it to me. Without your suggestions, Friday Q&A could not happen, so send them in!

Add your thoughts, post a comment:

Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.