Standard alternative to GCC's ##__VA_ARGS__ trick?

Question

There is a well-known problem with empty args for variadic macros in C99.

example:

#define FOO(...)       printf(__VA_ARGS__)
#define BAR(fmt, ...)  printf(fmt, __VA_ARGS__)

FOO("this works fine");
BAR("this breaks!");

The use of BAR() above is indeed incorrect according to the C99 standard, since it will expand to:

printf("this breaks!",);

Note the trailing comma - not workable.

Some compilers (eg: Visual Studio 2010) will quietly get rid of that trailing comma for you. Other compilers (eg: GCC) support putting ## in front of __VA_ARGS__, like so:

#define BAR(fmt, ...)  printf(fmt, ##__VA_ARGS__)

But is there a standards-compliant way to get this behavior? Perhaps using multiple macros?

Right now, the ## version seems fairly well-supported (at least on my platforms), but I'd really rather use a standards-compliant solution.

Pre-emptive: I know I could just write a small function. I'm trying to do this using macros.

Edit: Here is an example (though simple) of why I would want to use BAR():

#define BAR(fmt, ...)  printf(fmt "\n", ##__VA_ARGS__)

BAR("here is a log message");
BAR("here is a log message with a param: %d", 42);

This automatically adds a newline to my BAR() logging statements, assuming fmt is always a double-quoted C-string. It does NOT print the newline as a separate printf(), which is advantageous if the logging is line-buffered and coming from multiple sources asynchronously.

Solution 1

It is possible to avoid the use of GCC's ,##__VA_ARGS__ extension if you are willing to accept some hardcoded upper limit on the number of arguments you can pass to your variadic macro, as described in Richard Hansen's answer to this question. If you do not want to have any such limit, however, to the best of my knowledge it is not possible using only C99-specified preprocessor features; you must use some extension to the language. clang and icc have adopted this GCC extension, but MSVC has not.

Back in 2001 I wrote up the GCC extension for standardization (and the related extension that lets you use a name other than __VA_ARGS__ for the rest-parameter) in document N976, but that received no response whatsoever from the committee; I don't even know if anyone read it. In 2016 it was proposed again in N2023, and I encourage anyone who knows how that proposal is going to let us know in the comments.

Solution 2

There is an argument counting trick that you can use.

Here is one standard-compliant way to implement the second BAR() example in jwd's question:

#include <stdio.h>

#define BAR(...) printf(FIRST(__VA_ARGS__) "\n" REST(__VA_ARGS__))

/* expands to the first argument */
#define FIRST(...) FIRST_HELPER(__VA_ARGS__, throwaway)
#define FIRST_HELPER(first, ...) first

/*
 * if there's only one argument, expands to nothing.  if there is more
 * than one argument, expands to a comma followed by everything but
 * the first argument.  only supports up to 9 arguments but can be
 * trivially expanded.
 */
#define REST(...) REST_HELPER(NUM(__VA_ARGS__), __VA_ARGS__)
#define REST_HELPER(qty, ...) REST_HELPER2(qty, __VA_ARGS__)
#define REST_HELPER2(qty, ...) REST_HELPER_##qty(__VA_ARGS__)
#define REST_HELPER_ONE(first)
#define REST_HELPER_TWOORMORE(first, ...) , __VA_ARGS__
#define NUM(...) \
    SELECT_10TH(__VA_ARGS__, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE,\
                TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, ONE, throwaway)
#define SELECT_10TH(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, ...) a10

int
main(int argc, char *argv[])
{
    BAR("first test");
    BAR("second test: %s", "a string");
    return 0;
}

This same trick is used to:

• count the number of arguments
• expand differently depending on the number of arguments
• append to __VA_ARGS__

Explanation

The strategy is to separate __VA_ARGS__ into the first argument and the rest (if any). This makes it possible to insert stuff after the first argument but before the second (if present).

FIRST()

This macro simply expands to the first argument, discarding the rest.

The implementation is straightforward. The throwaway argument ensures that FIRST_HELPER() gets two arguments, which is required because the ... needs at least one. With one argument, it expands as follows:

1. FIRST(firstarg)
2. FIRST_HELPER(firstarg, throwaway)
3. firstarg

With two or more, it expands as follows:

1. FIRST(firstarg, secondarg, thirdarg)
2. FIRST_HELPER(firstarg, secondarg, thirdarg, throwaway)
3. firstarg

REST()

This macro expands to everything but the first argument (including the comma after the first argument, if there is more than one argument).

The implementation of this macro is far more complicated. The general strategy is to count the number of arguments (one or more than one) and then expand to either REST_HELPER_ONE() (if only one argument given) or REST_HELPER_TWOORMORE() (if two or more arguments given). REST_HELPER_ONE() simply expands to nothing -- there are no arguments after the first, so the remaining arguments is the empty set. REST_HELPER_TWOORMORE() is also straightforward -- it expands to a comma followed by everything except the first argument.

The arguments are counted using the NUM() macro. This macro expands to ONE if only one argument is given, TWOORMORE if between two and nine arguments are given, and breaks if 10 or more arguments are given (because it expands to the 10th argument).

The NUM() macro uses the SELECT_10TH() macro to determine the number of arguments. As its name implies, SELECT_10TH() simply expands to its 10th argument. Because of the ellipsis, SELECT_10TH() needs to be passed at least 11 arguments (the standard says that there must be at least one argument for the ellipsis). This is why NUM() passes throwaway as the last argument (without it, passing one argument to NUM() would result in only 10 arguments being passed to SELECT_10TH(), which would violate the standard).

Selection of either REST_HELPER_ONE() or REST_HELPER_TWOORMORE() is done by concatenating REST_HELPER_ with the expansion of NUM(__VA_ARGS__) in REST_HELPER2(). Note that the purpose of REST_HELPER() is to ensure that NUM(__VA_ARGS__) is fully expanded before being concatenated with REST_HELPER_.

Expansion with one argument goes as follows:

1. REST(firstarg)
2. REST_HELPER(NUM(firstarg), firstarg)
3. REST_HELPER2(SELECT_10TH(firstarg, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, ONE, throwaway), firstarg)
4. REST_HELPER2(ONE, firstarg)
5. REST_HELPER_ONE(firstarg)
6. (empty)

Expansion with two or more arguments goes as follows:

1. REST(firstarg, secondarg, thirdarg)
2. REST_HELPER(NUM(firstarg, secondarg, thirdarg), firstarg, secondarg, thirdarg)
3. REST_HELPER2(SELECT_10TH(firstarg, secondarg, thirdarg, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, TWOORMORE, ONE, throwaway), firstarg, secondarg, thirdarg)
4. REST_HELPER2(TWOORMORE, firstarg, secondarg, thirdarg)
5. REST_HELPER_TWOORMORE(firstarg, secondarg, thirdarg)
6. , secondarg, thirdarg

Solution 3

Not a general solution, but in the case of printf you could append a newline like:

#define BAR_HELPER(fmt, ...) printf(fmt "\n%s", __VA_ARGS__)
#define BAR(...) BAR_HELPER(__VA_ARGS__, "")

I believe it ignores any extra args that aren't referenced in the format string. So you could probably even get away with:

#define BAR_HELPER(fmt, ...) printf(fmt "\n", __VA_ARGS__)
#define BAR(...) BAR_HELPER(__VA_ARGS__, 0)

I can't believe C99 was approved without a standard way to do this. AFAICT the problem exists in C++11 too.

Solution 4

There is a way to handle this specific case using something like Boost.Preprocessor. You can use BOOST_PP_VARIADIC_SIZE to check the size of the argument list, and then conditionaly expand to another macro. The one shortcoming of this is that it can't distinguish between 0 and 1 argument, and the reason for this becomes clear once you consider the following:

BOOST_PP_VARIADIC_SIZE()      // expands to 1
BOOST_PP_VARIADIC_SIZE(,)     // expands to 2
BOOST_PP_VARIADIC_SIZE(,,)    // expands to 3
BOOST_PP_VARIADIC_SIZE(a)     // expands to 1
BOOST_PP_VARIADIC_SIZE(a,)    // expands to 2
BOOST_PP_VARIADIC_SIZE(,b)    // expands to 2
BOOST_PP_VARIADIC_SIZE(a,b)   // expands to 2
BOOST_PP_VARIADIC_SIZE(a, ,c) // expands to 3

The empty macro argument list actually consists of one argument that happens to be empty.

In this case, we are lucky since your desired macro always has at least 1 argument, we can implement it as two "overload" macros:

#define BAR_0(fmt) printf(fmt "\n")
#define BAR_1(fmt, ...) printf(fmt "\n", __VA_ARGS__)

And then another macro to switch between them, such as:

#define BAR(...) \
    BOOST_PP_CAT(BAR_, BOOST_PP_GREATER(
        BOOST_PP_VARIADIC_SIZE(__VA_ARGS__), 1))(__VA_ARGS__) \
    /**/

or

#define BAR(...) BOOST_PP_IIF( \
    BOOST_PP_GREATER(BOOST_PP_VARIADIC_SIZE(__VA_ARGS__), 1), \
        BAR_1, BAR_0)(__VA_ARGS__) \
    /**/

Whichever you find more readable (I prefer the first as it gives you a general form for overloading macros on the number of arguments).

It is also possible to do this with a single macro by accessing and mutating the variable arguments list, but it is way less readable, and is very specific to this problem:

#define BAR(...) printf( \
    BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__) "\n" \
    BOOST_PP_COMMA_IF( \
        BOOST_PP_GREATER(BOOST_PP_VARIADIC_SIZE(__VA_ARGS__), 1)) \
    BOOST_PP_ARRAY_ENUM(BOOST_PP_ARRAY_POP_FRONT( \
        BOOST_PP_VARIADIC_TO_ARRAY(__VA_ARGS__)))) \
    /**/

Also, why is there no BOOST_PP_ARRAY_ENUM_TRAILING? It would make this solution much less horrible.

Edit: Alright, here is a BOOST_PP_ARRAY_ENUM_TRAILING, and a version that uses it (this is now my favourite solution):

#define BOOST_PP_ARRAY_ENUM_TRAILING(array) \
    BOOST_PP_COMMA_IF(BOOST_PP_ARRAY_SIZE(array)) BOOST_PP_ARRAY_ENUM(array) \
    /**/

#define BAR(...) printf( \
    BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__) "\n" \
    BOOST_PP_ARRAY_ENUM_TRAILING(BOOST_PP_ARRAY_POP_FRONT( \
        BOOST_PP_VARIADIC_TO_ARRAY(__VA_ARGS__)))) \
    /**/

Solution 5

A very simple macro I'm using for debug printing:

#define DBG__INT(fmt, ...) printf(fmt "%s", __VA_ARGS__);
#define DBG(...) DBG__INT(__VA_ARGS__, "\n")

int main() {
        DBG("No warning here");
        DBG("and we can add as many arguments as needed. %s", "nice!");
        return 0;
}

No matter how many arguments are passed to DBG there are no c99 warning.

The trick is DBG__INT adding a dummy param so ... will always have at least one argument and c99 is satisfied.

View more solutions

Comments

[jwd]

@GMan: Read the last sentence (:

[Leushenko]

This feature has been proposed for inclusion in C2x.

[GManNickG]

Why use BAR instead of FOO in the first place?

[Leushenko]

@zwol the latest version submitted to WG14 looks like this, which uses a new syntax based on the __VA_OPT__ keyword. This has already been "adopted" by C++, so I expect C will follow suit. (don't know whether that means it was fast-tracked into C++17 or if it's set for C++20 though)

[jwd]

Judging by my disability to find a solution on the web and the lack of answers here, I guess you're right ):

[Richard Hansen]

Is n976 what you are referring to? I searched the rest of the C working group's documents for a response but never found one. It wasn't even in the agenda for the subsequent meeting. The only other hit on this topic was Norway's comment #4 in n868 back from before C99 was ratified (again with no follow-up discussion).

[zwol]

Yes, specifically the second half of that. There may have been discussion on comp.std.c but I was unable to find any in Google Groups just now; it certainly never got any attention from the actual committee (or if it did, nobody ever told me about it).

[Richard Hansen]

+1 for bringing up the argument counting trick, -1 for being really hard to follow

[Richard Hansen]

The comments you added were an improvement, but there are still a number of issues: 1. You discuss and define NUM_ARGS but don't use it. 2. What is the purpose of UNIMPLEMENTED? 3. You never solve the example problem in the question. 4. Walking through the expansion one step at a time would illustrate how it works and explain the role of each helper macro. 5. Discussing 0 arguments is distracting; the OP was asking about standards compliance, and 0 arguments is forbidden (C99 6.10.3p4). 6. Step 1.5? Why not step 2? 7. "Steps" implies actions that occur sequentially; this is just code.

[Richard Hansen]

8. You link to the whole blog, not the relevant post. I couldn't find the post you were referring to. 9. The last paragraph is awkward: This method is obscure; that's why nobody else had posted a correct solution before. Also, if it works and adheres to the standard, Zack's answer must be wrong. 10. You should define CONCAT() -- don't assume readers know how it works.

[Richard Hansen]

(Please don't interpret this feedback as an attack -- I really did want to upvote your answer but didn't feel comfortable doing so unless it was made easier to understand. If you can improve the clarity of your answer, I'll upvote yours and delete mine.)

[User123abc]

No, that was an honest question. I know that these macros can be hard. Since I already understand my post, I don't know which parts of it are confusing. Your approach is different in a useful way, so I think you shouldn't delete it. (It's more complicated in implementation, but it saves the user from having to define helper functions like _UNIMPLEMENTED1 and _UNIMPLEMENTED2 each time they want to use it).

[zwol]

I would never have thought of this approach, and I wrote roughly half of GCC's current preprocessor! That said, I do still say that "there is no standard way to get this effect" because both your and Richard's techniques impose an upper limit on the number of arguments to the macro.

[Richard Hansen]

Nice to learn about Boost.Preprocessor, +1. Note that BOOST_PP_VARIADIC_SIZE() uses the same argument counting trick I documented in my answer, and has the same limitation (it will break if you pass more than a certain number of arguments).

[DRayX]

Yep, I saw that your approach was the same one used by Boost, but the boost solution is very well maintained, and has a lot of other really useful features for use when developing more sophisticated macros. The recursion stuff is particularly cool (and used behind the scenes in the last approach that uses BOOST_PP_ARRAY_ENUM).

[Chris Dodd]

Note that this will fail if you call BAR with 10 or more arguments, and though it's relatively easy to extend to more arguments, it will always have a upper bound on the number of arguments it can deal with

[Richard Hansen]

@ChrisDodd: Correct. Unfortunately, there doesn't appear to be a way to avoid a limit in the number of arguments without relying on compiler-specific extensions. Also, I'm unaware of a way to reliably test if there are too many arguments (so that a useful compiler error message can be printed, rather than a strange failure).

[Aaron McDaid]

According to this answer to a related question there is a standard way to count the args to a macro. I don't understand any of it though!

[augurar]

Do you have a proof as to why this is impossible in standard C? I'm interested for theoretical reasons. See my question on the subject.

[zwol]

I'm afraid I don't have a proof, nor am I anymore the right person to try to think one up. I did write half of GCC's preprocessor, but that was more than ten years ago, and I'd never have thought of the argument-counting trick below, even then.

[Justin]

A Boost answer that actually applies to the c tag! Hooray!

[ACyclic]

This extension works with clang & intel icc compilers, as well as gcc.

[PSkocik]

This still triggers a warning when compiled with -pedantic.

[l4m2]

The no arg contain comma limitation may be bypassed by checking multi after some more passes, but no bracket still there

[Alex D]

Unfortunately, it works only with string arguments! BAR("val:%d", 1); fails to compile!