C++ preprocessor __VA_ARGS__ number of arguments
This is actually compiler dependent, and not supported by any standard.
Here however you have a macro implementation that does the count:
#define PP_NARG(...) \
PP_NARG_(__VA_ARGS__,PP_RSEQ_N())
#define PP_NARG_(...) \
PP_ARG_N(__VA_ARGS__)
#define PP_ARG_N( \
_1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \
_11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \
_21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \
_31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \
_41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \
_51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \
_61,_62,_63,N,...) N
#define PP_RSEQ_N() \
63,62,61,60, \
59,58,57,56,55,54,53,52,51,50, \
49,48,47,46,45,44,43,42,41,40, \
39,38,37,36,35,34,33,32,31,30, \
29,28,27,26,25,24,23,22,21,20, \
19,18,17,16,15,14,13,12,11,10, \
9,8,7,6,5,4,3,2,1,0
/* Some test cases */
PP_NARG(A) -> 1
PP_NARG(A,B) -> 2
PP_NARG(A,B,C) -> 3
PP_NARG(A,B,C,D) -> 4
PP_NARG(A,B,C,D,E) -> 5
PP_NARG(1,2,3,4,5,6,7,8,9,0,
1,2,3,4,5,6,7,8,9,0,
1,2,3,4,5,6,7,8,9,0,
1,2,3,4,5,6,7,8,9,0,
1,2,3,4,5,6,7,8,9,0,
1,2,3,4,5,6,7,8,9,0,
1,2,3) -> 63
A way to count the number of __VA_ARGS__ arguments, including 0, without compiler specific constructs
After some research, I found a blog post by Jens Gustedt named "Detect empty macro arguments" (which I found as a comment by him in this answer). Together with the counting solution found in another answer by H Walters (which is similar to this one) we can build a solution that should work in any C99 compiler. The code below is a unification of these two methods.
One noteworthy change I made was adding extra EXPAND macros. As discussed in this question, MSVC does not expand __VA_ARGS__ like most other compilers, so an extra step of expansion is necessary.
/* NOTE: In these macros, "1" means true, and "0" means false. */
#define EXPAND(x) x
#define _GLUE(X,Y) X##Y
#define GLUE(X,Y) _GLUE(X,Y)
/* Returns the 100th argument. */
#define _ARG_100(_,\
_100,_99,_98,_97,_96,_95,_94,_93,_92,_91,_90,_89,_88,_87,_86,_85,_84,_83,_82,_81, \
_80,_79,_78,_77,_76,_75,_74,_73,_72,_71,_70,_69,_68,_67,_66,_65,_64,_63,_62,_61, \
_60,_59,_58,_57,_56,_55,_54,_53,_52,_51,_50,_49,_48,_47,_46,_45,_44,_43,_42,_41, \
_40,_39,_38,_37,_36,_35,_34,_33,_32,_31,_30,_29,_28,_27,_26,_25,_24,_23,_22,_21, \
_20,_19,_18,_17,_16,_15,_14,_13,_12,_11,_10,_9,_8,_7,_6,_5,_4,_3,_2,X_,...) X_
/* Returns whether __VA_ARGS__ has a comma (up to 100 arguments). */
#define HAS_COMMA(...) EXPAND(_ARG_100(__VA_ARGS__, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 ,1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0))
/* Produces a comma if followed by a parenthesis. */
#define _TRIGGER_PARENTHESIS_(...) ,
#define _PASTE5(_0, _1, _2, _3, _4) _0 ## _1 ## _2 ## _3 ## _4
#define _IS_EMPTY_CASE_0001 ,
/* Returns true if inputs expand to (false, false, false, true) */
#define _IS_EMPTY(_0, _1, _2, _3) HAS_COMMA(_PASTE5(_IS_EMPTY_CASE_, _0, _1, _2, _3))
/* Returns whether __VA_ARGS__ is empty. */
#define IS_EMPTY(...) \
_IS_EMPTY( \
/* Testing for an argument with a comma \
e.g. "ARG1, ARG2", "ARG1, ...", or "," */ \
HAS_COMMA(__VA_ARGS__), \
/* Testing for an argument around parenthesis \
e.g. "(ARG1)", "(...)", or "()" */ \
HAS_COMMA(_TRIGGER_PARENTHESIS_ __VA_ARGS__), \
/* Testing for a macro as an argument, which will \
expand the parenthesis, possibly generating a comma. */ \
HAS_COMMA(__VA_ARGS__ (/*empty*/)), \
/* If all previous checks are false, __VA_ARGS__ does not \
generate a comma by itself, nor with _TRIGGER_PARENTHESIS_ \
behind it, nor with () after it. \
Therefore, "_TRIGGER_PARENTHESIS_ __VA_ARGS__ ()" \
only generates a comma if __VA_ARGS__ is empty. \
So, this tests for an empty __VA_ARGS__ (given the \
previous conditionals are false). */ \
HAS_COMMA(_TRIGGER_PARENTHESIS_ __VA_ARGS__ (/*empty*/)) \
)
#define _VAR_COUNT_EMPTY_1(...) 0
#define _VAR_COUNT_EMPTY_0(...) EXPAND(_ARG_100(__VA_ARGS__, \
100,99,98,97,96,95,94,93,92,91,90,89,88,87,86,85,84,83,82,81, \
80,79,78,77,76,75,74,73,72,71,70,69,68,67,66,65,64,63,62,61, \
60,59,58,57,56,55,54,53,52,51,50,49,48,47,46,45,44,43,42,41, \
40,39,38,37,36,35,34,33,32,31,30,29,28,27,26,25,24,23,22,21, \
20,19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1))
#define VAR_COUNT(...) GLUE(_VAR_COUNT_EMPTY_, IS_EMPTY(__VA_ARGS__))(__VA_ARGS__)
These are some example outputs:
#define EATER0(...)
#define EATER1(...) ,
#define EATER2(...) (/*empty*/)
#define EATER3(...) (/*empty*/),
#define EATER4(...) EATER1
#define EATER5(...) EATER2
#define MAC0() ()
#define MAC1(x) ()
#define MACV(...) ()
#define MAC2(x,y) whatever
VAR_COUNT() // 0
VAR_COUNT(/*comment*/) // 0
VAR_COUNT(a) // 1
VAR_COUNT(a, b) // 2
VAR_COUNT(a, b, c) // 3
VAR_COUNT(a, b, c, d) // 4
VAR_COUNT(a, b, c, d, e) // 5
VAR_COUNT((a, b, c, d, e)) // 1
VAR_COUNT((void)) // 1
VAR_COUNT((void), c, d) // 3
VAR_COUNT((a, b), c, d) // 3
VAR_COUNT(_TRIGGER_PARENTHESIS_) // 1
VAR_COUNT(EATER0) // 1
VAR_COUNT(EATER1) // 1
VAR_COUNT(EATER2) // 1
VAR_COUNT(EATER3) // 1
VAR_COUNT(EATER4) // 1
VAR_COUNT(MAC0) // 1
VAR_COUNT(MAC1) // 1
VAR_COUNT(MACV) // 1
/* This one will fail because MAC2 is not called correctly. */
VAR_COUNT(MAC2) // error
/* But only if it's at the end spot. */
VAR_COUNT(MACV, MAC1, MAC2) // error
VAR_COUNT(MAC2, MAC1, MACV) // 3
As pointed out by Jens Gustedt in his blog post, this solution has a flaw. Quote:
In fact ISEMPTY should work when it is called with macros as argument that expect
0,1or a variable list of arguments. If called with a macroXas an argument that itself expects more than one argument (such asMAC2) the expansion leads to an invalid use of that macroX.
So, if the list passed contains a function-like macro at the end that requires two or more arguments (such as MAC2), VAR_COUNT will fail.
Other than that, I've tested the macros on GCC 9.3.0 and Visual Studio 2019, and it should also work with any C99 (or more recent) compiler.
Any modification that fixes the flaw mentioned above is appreciated.
Count number of variadic arguments in macro function
_1 to _10 are just placeholders from the start in order to make sure N is positioned over the correct number from 10 to 0 (depending on __VA_ARGS__). They serve no purpose other than occupying a position.
Since each macro parameter must have a distinct identifier, those identifiers are as good as any.
Regarding your edit, that is limitation of the preprocessor. An empty token sequence is a valid argument to a macro. So it really is a single argument, because __VA_ARGS__ , (note the comma) becomes such an argument.
It's quite a known issue, so much so that C++20 added the __VA_OPT__ preprocessor macro. It allows to add the comma conditionally. On C++20, the implementation can be fixed to work as expected like this:
#define CV_VA_NUM_ARGS(...) CV_VA_NUM_ARGS_HELPER(__VA_ARGS__ __VA_OPT__(,) 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
Limit of preprocessor __VA_ARGS__ length?
The only thing I can find is this bit in C99 (C11 still contains the same text):
5.2.4.1 Translation limits
The implementation shall be able to translate and execute at least one program that
contains at least one instance of every one of the following limits:13)
- [...]
- 127 arguments in one macro invocation
- [...]
- 4095 characters in a character string literal or wide string literal (after concatenation)
- [...]
[...]
13) Implementations should avoid imposing fixed translation limits whenever possible.
So according to the standard there is no fixed limit. You will have to check whether your compiler documents any limits or just tries to support whatever you throw at it (until it runs out of RAM or something).
Macro to count number of arguments
Another possibility, which does not use sizeof nor a GCC extension is to add the following to your code
#define PP_COMMASEQ_N() \
1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
1, 1, 1, 1, 1, 1, 1, 1, 0, 0
#define PP_COMMA(...) ,
#define PP_HASCOMMA(...) \
PP_NARG_(__VA_ARGS__, PP_COMMASEQ_N())
#define PP_NARG(...) \
PP_NARG_HELPER1( \
PP_HASCOMMA(__VA_ARGS__), \
PP_HASCOMMA(PP_COMMA __VA_ARGS__ ()), \
PP_NARG_(__VA_ARGS__, PP_RSEQ_N()))
#define PP_NARG_HELPER1(a, b, N) PP_NARG_HELPER2(a, b, N)
#define PP_NARG_HELPER2(a, b, N) PP_NARG_HELPER3_ ## a ## b(N)
#define PP_NARG_HELPER3_01(N) 0
#define PP_NARG_HELPER3_00(N) 1
#define PP_NARG_HELPER3_11(N) N
The result is
PP_NARG() // expands to 0
PP_NARG(x) // expands to 1
PP_NARG(x, 2) // expands to 2
Explanation:
The trick in these macros is that PP_HASCOMMA(...) expands to 0 when called with zero or one argument and to 1 when called with at least two arguments. To distinguish between these two cases, I used PP_COMMA __VA_ARGS__ (), which returns a comma when __VA_ARGS__ is empty and returns nothing when __VA_ARGS__ is non-empty.
Now there are three possible cases:
__VA_ARGS__is empty:PP_HASCOMMA(__VA_ARGS__)returns 0 andPP_HASCOMMA(PP_COMMA __VA_ARGS__ ())returns 1.__VA_ARGS__contains one argument:PP_HASCOMMA(__VA_ARGS__)returns 0 andPP_HASCOMMA(PP_COMMA __VA_ARGS__ ())returns 0.__VA_ARGS__contains two or more arguments:PP_HASCOMMA(__VA_ARGS__)returns 1 andPP_HASCOMMA(PP_COMMA __VA_ARGS__ ())returns 1.
The PP_NARG_HELPERx macros are just needed to resolve these cases.
Edit:
In order to fix the func(0, ) problem, we need to test whether we have supplied zero
or more arguments. The PP_ISZERO macro comes into play here.
#define PP_ISZERO(x) PP_HASCOMMA(PP_ISZERO_HELPER_ ## x)
#define PP_ISZERO_HELPER_0 ,
Now let's define another macro which prepends the number of arguments to an argument list:
#define PP_PREPEND_NARG(...) \
PP_PREPEND_NARG_HELPER1(PP_NARG(__VA_ARGS__), __VA_ARGS__)
#define PP_PREPEND_NARG_HELPER1(N, ...) \
PP_PREPEND_NARG_HELPER2(PP_ISZERO(N), N, __VA_ARGS__)
#define PP_PREPEND_NARG_HELPER2(z, N, ...) \
PP_PREPEND_NARG_HELPER3(z, N, __VA_ARGS__)
#define PP_PREPEND_NARG_HELPER3(z, N, ...) \
PP_PREPEND_NARG_HELPER4_ ## z (N, __VA_ARGS__)
#define PP_PREPEND_NARG_HELPER4_1(N, ...) 0
#define PP_PREPEND_NARG_HELPER4_0(N, ...) N, __VA_ARGS__
The many helpers are again needed to expand the macros to numeric values. Finally test it:
#define my_func(...) func(PP_PREPEND_NARG(__VA_ARGS__))
my_func() // expands to func(0)
my_func(x) // expands to func(1, x)
my_func(x, y) // expands to func(2, x, y)
my_func(x, y, z) // expands to func(3, x, y, z)
Online example:
http://coliru.stacked-crooked.com/a/73b4b6d75d45a1c8
See also:
Please have also a look at the P99 project, which has much more
advanced preprocessor solutions, like these.
Macro returning the number of arguments it is given in C? [duplicate]
It can be done - the mechanism was explained in the comp.std.c newsgroup in January 2006. There was another question about this recently on SO 2124339.
I stashed the code away, just in case...
#ifndef JLSS_ID_NARG_H
#define JLSS_ID_NARG_H
/*
** http://groups.google.com/group/comp.std.c/browse_thread/thread/77ee8c8f92e4a3fb/346fc464319b1ee5?pli=1
**
** Newsgroups: comp.std.c
** From: Laurent Deniau <laurent.deniau@cern.ch>
** Date: Mon, 16 Jan 2006 18:43:40 +0100
** Subject: __VA_NARG__
**
** A year ago, I was asking here for an equivalent of __VA_NARG__ which
** would return the number of arguments contained in __VA_ARGS__ before its
** expansion. In fact my problem at that time (detecting for a third
** argument) was solved by the solution of P. Mensonides. But I was still
** thinking that the standard should have provided such a facilities rather
** easy to compute for cpp.
**
** This morning I had to face again the same problem, that is knowing the
** number of arguments contained in __VA_ARGS__ before its expansion (after
** its expansion can always be achieved if you can do it before). I found a
** simple non-iterative solution which may be of interest here as an answer
** to who will ask in the future for a kind of __VA_NARG__ in the standard
** and I post it for archiving. May be some more elegant-efficient solution
** exists?
**
** Returns NARG, the number of arguments contained in __VA_ARGS__ before
** expansion as far as NARG is >0 and <64 (cpp limits):
**
** #define PP_NARG( ...) PP_NARG_(__VA_ARGS__,PP_RSEQ_N())
** #define PP_NARG_(...) PP_ARG_N(__VA_ARGS__)
** #define PP_ARG_N(_1,_2,_3,_4,_5,_6,_7,_8,_9,[..],_61,_62,_63,N,...) N
** #define PP_RSEQ_N() 63,62,61,60,[..],9,8,7,6,5,4,3,2,1,0
**
** [..] stands for the continuation of the sequence omitted here for
** lisibility.
**
** PP_NARG(A) -> 1
** PP_NARG(A,B) -> 2
** PP_NARG(A,B,C) -> 3
** PP_NARG(A,B,C,D) -> 4
** PP_NARG(A,B,C,D,E) -> 5
** PP_NARG(A1,A2,[..],A62,A63) -> 63
**
** ======
**
** Newsgroups: comp.std.c
** From: Roland Illig <roland.il...@gmx.de>
** Date: Fri, 20 Jan 2006 12:58:41 +0100
** Subject: Re: __VA_NARG__
**
** Laurent Deniau wrote:
** > This morning I had to face again the same problem, that is knowing the
** > number of arguments contained in __VA_ARGS__ before its expansion (after
** > its expansion can always be achieved if you can do it before). I found a
** > simple non-iterative solution which may be of interest here as an answer
** > to who will ask in the future for a kind of __VA_NARG__ in the standard
** > and I post it for archiving. May be some more elegant-efficient solution
** > exists?
**
** Thanks for this idea. I really like it.
**
** For those that only want to copy and paste it, here is the expanded version:
**
** // Some test cases
** PP_NARG(A) -> 1
** PP_NARG(A,B) -> 2
** PP_NARG(A,B,C) -> 3
** PP_NARG(A,B,C,D) -> 4
** PP_NARG(A,B,C,D,E) -> 5
** PP_NARG(1,2,3,4,5,6,7,8,9,0, // 1..10
** 1,2,3,4,5,6,7,8,9,0, // 11..20
** 1,2,3,4,5,6,7,8,9,0, // 21..30
** 1,2,3,4,5,6,7,8,9,0, // 31..40
** 1,2,3,4,5,6,7,8,9,0, // 41..50
** 1,2,3,4,5,6,7,8,9,0, // 51..60
** 1,2,3) -> 63
**
**Note: using PP_NARG() without arguments would violate 6.10.3p4 of ISO C99.
*/
/* The PP_NARG macro returns the number of arguments that have been
** passed to it.
*/
#define PP_NARG(...) \
PP_NARG_(__VA_ARGS__,PP_RSEQ_N())
#define PP_NARG_(...) \
PP_ARG_N(__VA_ARGS__)
#define PP_ARG_N( \
_1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \
_11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \
_21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \
_31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \
_41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \
_51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \
_61,_62,_63, N, ...) N
#define PP_RSEQ_N() \
63,62,61,60, \
59,58,57,56,55,54,53,52,51,50, \
49,48,47,46,45,44,43,42,41,40, \
39,38,37,36,35,34,33,32,31,30, \
29,28,27,26,25,24,23,22,21,20, \
19,18,17,16,15,14,13,12,11,10, \
9, 8, 7, 6, 5, 4, 3, 2, 1, 0
#endif /* JLSS_ID_NARG_H */
It works fine as long as there are no more than 64 arguments. Here's the test code I used:
#include "narg.h"
#include <stdio.h>
#define PRINT(pp_narg) printf("%2d = %s\n", pp_narg, # pp_narg)
#ifndef lint
/* Prevent over-aggressive optimizers from eliminating ID string */
extern const char jlss_id_narg_c[];
const char jlss_id_narg_c[] = "@(#)$Id: narg.c,v 1.2 2010/01/24 18:12:05 jleffler Exp $";
#endif /* lint */
int
main(void)
{
PRINT(PP_NARG(A));
PRINT(PP_NARG(A, B));
PRINT(PP_NARG(A, B, C));
PRINT(PP_NARG(A, B, C, D));
PRINT(PP_NARG(A, B, C, D, E));
PRINT(PP_NARG(1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 1..10
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 11..20
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 21..30
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 31..40
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 41..50
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 51..60
1, 2, 3));
/**
** If the number of arguments to PP_NARG() is greater than 63, the
** 64th argument is returned. This is well-defined behaviour, but
** not exactly what was intended.
*/
PRINT(PP_NARG(1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 1..10
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 11..20
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 21..30
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 31..40
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 41..50
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 51..60
1, 2, 3, -123456789));
PRINT(PP_NARG(1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 1..10
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 11..20
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 21..30
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 31..40
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 41..50
1, 2, 3, 4, 5, 6, 7, 8, 9, 0, // 51..60
1, 2, 3, -123456789, -987654321));
return(0);
}
Using __VA_ARGS__ in a nested macro, but the args are truncated
Your initial code:
#define AA(mac, a, ...) mac(a, __VA_ARGS__)
#define MAC1(a, b, c) a##b##c
AA(MAC1, 0, 1, 2)
seems to work fine:
$ gcc -E a.c > a.pp ; cat a.pp
# 1 "a.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "a.c"
012
So, maybe there's an issue with your compiler or IDE.
Related Topics
Calling Virtual Functions Inside Constructors
Can Num++ Be Atomic For 'Int Num'
C/C++ Maximum Stack Size of Program on Mainstream Oses
Running My C++ Code Gives Me a Blank Console
How to Call a Constructor from Another Constructor (Do Constructor Chaining) in C++
Definitive List of Common Reasons For Segmentation Faults
C++ Delete - It Deletes My Objects But I Can Still Access the Data
Why Is Integer Assignment on a Naturally Aligned Variable Atomic on X86
Read Whole Ascii File into C++ Std::String
How to Initialize Private Static Members in C++
Function Pointer to Member Function
Why Are Preprocessor Macros Evil and What Are the Alternatives
How to Execute a Command and Get the Output of the Command Within C++ Using Posix
Difference Between New/Delete and Malloc/Free
What Are the Advantages of List Initialization (Using Curly Braces)