Rectangle 27 19

The easiest way to do your specific example would be with a variadic macro:

#define DEBUG_TRACE(...)                                        \
    do {                                                        \
        std::string p[] = { __VA_ARGS__ };                      \
        log _log(__FUNCTION__, p, (sizeof p) / (sizeof p[0]));  \
    } while (0)
  • __VA_ARGS__ is the name for the list of comma-separated arguments supplied to the macro
  • You can find out how many there are in your case using sizeof since p is a static array
  • Surrounding your macro code in do..while is often considered good practice because it gives variables (p) a block scope so users can still have a variable with the same name outside the macro, and the while (0) portion nicely accepts a semicolon afterwards without breaking one line if statements

If you need more flexibility than this, you can use a very neat trick to allow you to explicitly "overload" the macro to behave completely differently with a different number of parameters. However, this makes the code much more convoluted and should only be used if it is absolutely necessary. Since it seems like variadic arguments will do fine for your use case, I'll just provide a link: http://cplusplus.co.il/2010/07/17/variadic-macro-to-count-number-of-arguments/

do while

Obviously only a typo but the macro expands to just do {. The rest of the lines except the last need to be slashed too.

+1 for prompting me to double-check a heavily used logging macro, and thereby defusing a ticking time bomb...

c++ - Overload C macros - Stack Overflow

c++ c overloading c-preprocessor
Rectangle 27 18

You can use various recursive macro techniques to do things with variadic macros. For example, you can define a NUM_ARGS macro that counts the number of arguments to a variadic macro:

#define _NUM_ARGS(X100, X99, X98, X97, X96, X95, X94, X93, X92, X91, X90, X89, X88, X87, X86, X85, X84, X83, X82, X81, X80, X79, X78, X77, X76, X75, X74, X73, X72, X71, X70, X69, X68, X67, X66, X65, X64, X63, X62, X61, X60, X59, X58, X57, X56, X55, X54, X53, X52, X51, X50, X49, X48, X47, X46, X45, X44, X43, X42, X41, X40, X39, X38, X37, X36, X35, X34, X33, X32, X31, X30, X29, X28, X27, X26, X25, X24, X23, X22, X21, X20, X19, X18, X17, X16, X15, X14, X13, X12, X11, X10, X9, X8, X7, X6, X5, X4, X3, X2, X1, N, ...)   N

#define NUM_ARGS(...) _NUM_ARGS(__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)

Then with that, you can write a FOREACH macro that expands another macro for each element of a list:

#define EXPAND(X)       X
#define FIRSTARG(X, ...)    (X)
#define RESTARGS(X, ...)    (__VA_ARGS__)
#define FOREACH(MACRO, LIST)    FOREACH_(NUM_ARGS LIST, MACRO, LIST)
#define FOREACH_(N, M, LIST)    FOREACH__(N, M, LIST)
#define FOREACH__(N, M, LIST)   FOREACH_##N(M, LIST)
#define FOREACH_1(M, LIST)  M LIST
#define FOREACH_2(M, LIST)  EXPAND(M FIRSTARG LIST) FOREACH_1(M, RESTARGS LIST)
#define FOREACH_3(M, LIST)  EXPAND(M FIRSTARG LIST) FOREACH_2(M, RESTARGS LIST)
        :

Which will in turn allow you to to define your macro that stringifies each of its arguments:

#define STRINGIFY(X)    #X
#define MY_VARIADIC_MACRO(...)    FOREACH(STRINGIFY, (__VA_ARGS__))

I'm aware of those recursive techniques, but as seen from above they are tedious and they also have the unfortunate restriction that you're limited to the number of args you account for at compile time. I'll update my answer soon with the details of that solution that is not as tedious to implement and is not restricted to a predefined max which is easier to maintain. It might be the best solution for all cases, but for what I need it is a better answer than above. Thanks for the input though!

Is there a way to use C++ preprocessor stringification on variadic mac...

c++ macros arguments variadic stringification
Rectangle 27 7

I can show you how to do it in a variadic macro, so we can write this:

if(EQI(a, b, c, d, e, f))
#include <stdarg.h>
#include <stddef.h>

#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int))
#define EQI(...) ( \
    alleqi(NUMARGS(__VA_ARGS__), __VA_ARGS__))

/* takes count number of int arguments */
int alleqi(size_t count, ...)
{
    va_list va;
    va_start(va, count);

    int v0 = va_arg(va, int);

    for (; count > 1; count--) {
        if (v0 != va_arg(va, int)) {
            break;
        }
    }

    va_end(va);
    return count == 1;
}

Please be advised the above only works for int arguments (and probably other types whose size is the same as int, though I am bracing for someone to accuse me of promoting undefined behavior if I advertise that!).

Thanks to this prior post for figuring out how to count arguments in a variadic macro: https://stackoverflow.com/a/2124433/4323

@bph: I made it EQI now, though I think it's OK to use it on any four-byte quantities. We could make an EQL for eight-byte quantities. You can even assert() the size of the first argument is correct, but beyond that is tedious.

count

c - Comparison of several integer values for equality - Stack Overflow

c
Rectangle 27 1

From wikipedia, what you're looking for is a variadic macro:

A variadic macro is a feature of some computer programming languages, especially the C preprocessor, whereby a macro may be declared to accept a varying number of arguments.

Variable-argument macros were introduced in 1999 in the ISO/IEC 9899:1999 (C99) revision of the C language standard, and in 2011 in ISO/IEC 14882:2011 (C++11) revision of the C++ language standard.

So it is available in C++11 or in C99. It is available as en extension on some compiler too, for example GNU GCC supports it, and I think I read that VC++ too.

Then for the syntax, have a look at this post for example, which gives a straightforward example:

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

Unfortunately, he doesn't want to invoke printf(); he wants to generate code that compares the first argument with each of the remaining arguments in turn. You've not shown how to do that yet.

That precisely my problem I know how to Make a variadic macro, the hard part for me is to make the or like I mentioned

I still cant figure out how, could you give me an examples on how to do it please?

C++ macro with a variable number of arguments - Stack Overflow

c++ macros
Rectangle 27 1

From wikipedia, what you're looking for is a variadic macro:

A variadic macro is a feature of some computer programming languages, especially the C preprocessor, whereby a macro may be declared to accept a varying number of arguments.

Variable-argument macros were introduced in 1999 in the ISO/IEC 9899:1999 (C99) revision of the C language standard, and in 2011 in ISO/IEC 14882:2011 (C++11) revision of the C++ language standard.

So it is available in C++11 or in C99. It is available as en extension on some compiler too, for example GNU GCC supports it, and I think I read that VC++ too.

Then for the syntax, have a look at this post for example, which gives a straightforward example:

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

Unfortunately, he doesn't want to invoke printf(); he wants to generate code that compares the first argument with each of the remaining arguments in turn. You've not shown how to do that yet.

That precisely my problem I know how to Make a variadic macro, the hard part for me is to make the or like I mentioned

I still cant figure out how, could you give me an examples on how to do it please?

C++ macro with a variable number of arguments - Stack Overflow

c++ macros
Rectangle 27 7

Okay, I didn't mean to answer my own question here, but I've come up with a decent solution that is somewhat of a combination of Mark Wilkins answer and the example I gave in the question.

It is possible to stringify the entire set variadic set, which then includes the delimiting commas in the string. Here's a quick example:

#define MY_VARIADIC_MACRO(X...) printf(#X)

Using the above macro shows you that the entire set of arguments passed to the macro gets stringified.

Then you can then define a function to tokenize these arguments using the delimiting comma, thereby getting the set of tokenized strings by using the variadic macro:

#define MY_VARIADIC_MACRO(X...) tokenize_my_arguments(#X)

Then there's actually no longer the dependency of having the variadic macro call a variadic function and I can iterate nicely through my array of constant C strings rather than iterating through va_arg.

* New Stuff from Edit Follows *

Per Tim's comment, here's the details of the solution. Please forgive any errors since it was done in haste and I had to port from what I'm working on. Also, it's not meant to be copy/paste solution since it only outputs the stringification of the arguments to demonstrate POC, but should be sufficient enough to demonstrate the functionality.

Although this solution requires some run time computation, variadic macros often times call variadic functions and requires iterating through va_args, so the iteration takes place in finding the tokens, although a bit of performance is probably sacrificed. However, for maintainability, versatility, and ease of implementation, this seems to be the best option at the moment:

#define VARIADIC_STRINGIFY(_ARGUMENTS_TO_STRINGIFY...) Variadic_Stringification_Without_Variadic_Function(#_ARGUMENTS_TO_STRINGIFY)

void Variadic_Stringification_Without_Variadic_Function (const char* _stringified_arguments)
{
    strcpy(converted_arguments, _stringified_arguments);

    for(char* token = strtok(converted_arguments, ","); token != 0x0; token = strtok(0x0, ","))
        std::cout << token << std::endl;
}

Also, another nice feature of this is that I can easily find the number of arguments without having to have some type of information passed through the macro to determine where the arguments in the list ends.

Interesting, but before you mark this as a solution, post your actual code that solved this. I'm sure it will come in handy for others.

@Tim Will do, I've already tested a simple case and will make it a nicer example... have some deadlines and will post either tomorrow (5/11/2011) or the following day.

@Tim Updated with the details.

+1. It seems a good solution. I did not realize C99 supported variadic macros. Nice. I am using a Microsoft compiler that doesn't support it (at least not in that form).

Is there a way to use C++ preprocessor stringification on variadic mac...

c++ macros arguments variadic stringification
Rectangle 27 46

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.

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

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

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

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.

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

c - Standard alternative to GCC's ##__VA_ARGS__ trick? - Stack Overflo...

c c99 c-preprocessor variadic-macros
Rectangle 27 45

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.

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

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

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

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.

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

c - Standard alternative to GCC's ##__VA_ARGS__ trick? - Stack Overflo...

c c99 c-preprocessor variadic-macros
Rectangle 27 5

Having now grasped exactly how the VC++10 compiler bug works, I was able to come up with such a macro myself, based on the latter part of this answer.

#define EXPAND(x) x
#define FOR_EACH_1(what, x, ...) what(x)
#define FOR_EACH_2(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_1(what,  __VA_ARGS__))
#define FOR_EACH_3(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_2(what, __VA_ARGS__))
#define FOR_EACH_4(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_3(what,  __VA_ARGS__))
#define FOR_EACH_5(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_4(what,  __VA_ARGS__))
#define FOR_EACH_6(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_5(what,  __VA_ARGS__))
#define FOR_EACH_7(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_6(what,  __VA_ARGS__))
#define FOR_EACH_8(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_7(what,  __VA_ARGS__))
#define FOR_EACH_NARG(...) FOR_EACH_NARG_(__VA_ARGS__, FOR_EACH_RSEQ_N())
#define FOR_EACH_NARG_(...) EXPAND(FOR_EACH_ARG_N(__VA_ARGS__))
#define FOR_EACH_ARG_N(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N
#define FOR_EACH_RSEQ_N() 8, 7, 6, 5, 4, 3, 2, 1, 0
#define CONCATENATE(x,y) x##y
#define FOR_EACH_(N, what, ...) EXPAND(CONCATENATE(FOR_EACH_, N)(what, __VA_ARGS__))
#define FOR_EACH(what, ...) FOR_EACH_(FOR_EACH_NARG(__VA_ARGS__), what, __VA_ARGS__)
#define callMember(o, f) o.f();
#define callMember_o(f) callMember(o, f)
FOR_EACH(callMember_o, doSomething, doSomethingElse);

is the same as

o.doSomething(); o.doSomethingElse();

This solution is similar to that in the linked answer, except that the zero length variadic argument list in FOR_EACH(what, x, ...) when called with one element caused a spurious comma that makes FOR_EACH_NARG count 2 arguments instead of 1 argument, and the EXPAND macro workaround is used.

The bug in VC++10 is that if __VA_ARGS__ is passed to a macro within the definition of a variadic macro, it is evaluated after substitution into the macro, causing multiple comma separated arguments to be treated as one. To get around this you must delay argument evaluation until after __VA_ARGS__ is substituted, by wrapping the macro call in EXPAND, forcing the macro call to be evaluated as a string, substituting __VA_ARGS__ to do so. Only after the substitution into EXPAND is the macro called, by which point the variadic arguments are already substituted.

P.S. I would be grateful if anyone can suggest a method for compactly producing FOR_EACH_N macros for much larger values of N.

warning: ISO C99 requires rest arguments to be used

c++ - Preprocessor variadic FOR_EACH macro compatible with MSVC++10 - ...

c++ visual-c++ foreach variadic-macros
Rectangle 27 5

Having now grasped exactly how the VC++10 compiler bug works, I was able to come up with such a macro myself, based on the latter part of this answer.

#define EXPAND(x) x
#define FOR_EACH_1(what, x, ...) what(x)
#define FOR_EACH_2(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_1(what,  __VA_ARGS__))
#define FOR_EACH_3(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_2(what, __VA_ARGS__))
#define FOR_EACH_4(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_3(what,  __VA_ARGS__))
#define FOR_EACH_5(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_4(what,  __VA_ARGS__))
#define FOR_EACH_6(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_5(what,  __VA_ARGS__))
#define FOR_EACH_7(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_6(what,  __VA_ARGS__))
#define FOR_EACH_8(what, x, ...)\
  what(x);\
  EXPAND(FOR_EACH_7(what,  __VA_ARGS__))
#define FOR_EACH_NARG(...) FOR_EACH_NARG_(__VA_ARGS__, FOR_EACH_RSEQ_N())
#define FOR_EACH_NARG_(...) EXPAND(FOR_EACH_ARG_N(__VA_ARGS__))
#define FOR_EACH_ARG_N(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N
#define FOR_EACH_RSEQ_N() 8, 7, 6, 5, 4, 3, 2, 1, 0
#define CONCATENATE(x,y) x##y
#define FOR_EACH_(N, what, ...) EXPAND(CONCATENATE(FOR_EACH_, N)(what, __VA_ARGS__))
#define FOR_EACH(what, ...) FOR_EACH_(FOR_EACH_NARG(__VA_ARGS__), what, __VA_ARGS__)
#define callMember(o, f) o.f();
#define callMember_o(f) callMember(o, f)
FOR_EACH(callMember_o, doSomething, doSomethingElse);

is the same as

o.doSomething(); o.doSomethingElse();

This solution is similar to that in the linked answer, except that the zero length variadic argument list in FOR_EACH(what, x, ...) when called with one element caused a spurious comma that makes FOR_EACH_NARG count 2 arguments instead of 1 argument, and the EXPAND macro workaround is used.

The bug in VC++10 is that if __VA_ARGS__ is passed to a macro within the definition of a variadic macro, it is evaluated after substitution into the macro, causing multiple comma separated arguments to be treated as one. To get around this you must delay argument evaluation until after __VA_ARGS__ is substituted, by wrapping the macro call in EXPAND, forcing the macro call to be evaluated as a string, substituting __VA_ARGS__ to do so. Only after the substitution into EXPAND is the macro called, by which point the variadic arguments are already substituted.

P.S. I would be grateful if anyone can suggest a method for compactly producing FOR_EACH_N macros for much larger values of N.

warning: ISO C99 requires rest arguments to be used

c++ - Preprocessor variadic FOR_EACH macro compatible with MSVC++10 - ...

c++ visual-c++ foreach variadic-macros
Rectangle 27 8

The workaround in question is this:

#define EXPAND( x ) x
#define F(x, ...) X = x and VA_ARGS = __VA_ARGS__
#define G(...) EXPAND( F(__VA_ARGS__) )

The idea is that given an existing variadic macro F():

#define F(x, ...) X = x and VA_ARGS = __VA_ARGS__

instead of writing your desired variadic wrapper macro as, in this case, ...

#define G(...) F(__VA_ARGS__)

... you write G() with use of the additional EXPAND() macro. The actual definition of F() is not the point, and in particular it doesn't matter for this example that macro expansion does not produce valid C code. Its purpose is to demonstrate the preprocessor's behavior with respect to macro arguments. Specifically, it shows that although MSVC expands __VA_ARGS__ to a single token in a variadic macro, that can be worked around by forcing a double expansion.

For example, using the workaround definition, the preprocessor first expands ...

G(1, 2, 3)
EXPAND( F(1, 2, 3) )

... where the 1, 2, 3 is treated as a single token. That tokenization no longer matters when the preprocessor rescans for additional replacements, however: it sees the 1, 2, 3 as separate arguments to macro F(), and expands that as desired to produce the argument to macro EXPAND(), which just replaces it with itself.

If you think it odd that this works as intended, but the version without EXPAND() does not work (in MSVC), you are right.

It works, thanks. I also understand it better now. Calling the macro where the arguments are supposed to be expanded using another macro causes the compiler to expand the arguments correctly.

Actually my case is little bit different. I would like to overload based on the number of arguments : 1 arg -> method for 1 arg, 2 args -> method for 2 args. BUT : I would also like that >2 args -> method for 2 args + va args, since the two overloads for my macro can have an arg list after the their mandatory parameters. This causes me a problem, because when i call my method with > 2 args, then the 3rd argument is used as the method name, which is wrong.

The solution i can think of is to hardcode a maximum number of arguments in the macro that returns the actual macro name (i.e GET_MACRO() in the linked question). This would be done by redirecting to the overload with 2 args until say 32 args. But that seems a little dirty. Would you have an idea on how to handle that more clearly ? Though don't waste your time if it doesn't come to mind easily. Thanks.

c - __VA_ARGS__ expansion using MSVC - Stack Overflow

c visual-c++ macros variadic-macros
Rectangle 27 4

#define FUNC(...) do_something(__VA_ARGS__)

This is not possible before C++11, except as an extension.

However, using macros is not necessary in C++ for this at all (and would be considered poor style, since it is unsafe). Simply do them as functions with default arguments.

void FUNC(int x = 0)
{
    do_something(x);
}

FUNC();    // calls FUNC(0)
FUNC(1);

or as an overloaded function

void FUNC()
{
    do_something();  // can remove brackets here, although getting it to compile cleanly would be interesting
}

void FUNC(int x)
{
     do_something(x);
}

FUNC();
FUNC(1);

The latter does assume that do_something() is either overloaded or has an argument with a default value.

These options work in all versions of C++.

It's not trivial at all with variadic macros. What you have, do_something(__VA_ARGS__), cannot easily be extended to do_something_else (like the OP asks) when __VA_ARGS__ is empty. But agreed with the rest of your answer: if avoiding macros for this is possible, it's almost certainly better. (I see the OP edited the question, and it wasn't clear from the question initially.)

@Rob, Variadic macros have been part of the preprocessor for decades (since C99), they are not new in C++11. You may be thinking of variadic templates.

@jwfearn Variadic macros were only part of the preprocessor because most C++ compilers also handle C. They weren't added to C++ until C++11 though; before that, it was the compiler letting you use non-C++ C features.

@hvd: The OP edited his post since I replied. The original version did not have a reference to "do_something_different" like the current version does.

@jwfearn: Varadic macros were not part of C++ before C++11. The C99 preprocessor has never been the C++ preprocessor - at least as far as the standards are concerned. As I said, some C++ compilers before 2011 (most of which happen to also be C99 compilers) - but not all - supported it as an extension.

c preprocessor - C++ Macro with either 0 or 1 parameter - Stack Overfl...

c++ c-preprocessor
Rectangle 27 1

This can be accomplished using the Issue Navigator. I wrote a blog article discussing this in depth at:

The following are the key pieces from the article.

Objective-C temporary logging and FIXME markers

Add the following to a common header file:

#define DO_PRAGMA(x) _Pragma (#x)

#define FIXME(x) DO_PRAGMA(message (STR(__LINE__) " FIXME: " #x))

#define CLOG(x) NSLog(@#x); DO_PRAGMA(message (STR(__LINE__) " NSLog: " #x))

// If ENABLE_PRAGMA_FOR_FLOG is set, FLOG and NLOG both use pragma. 
// If not set, only NLOG uses pragma.
#if ENABLE_PRAGMA_FOR_FLOG
#define FLOG(LogType, MacroType, FormatLiteral, ...)  NSLog (@"%s(%u): " LogType " \n" FormatLiteral "\n\n", __FUNCTION__, __LINE__, ##__VA_ARGS__);  DO_PRAGMA(message (STR(__LINE__) " " MacroType ": " FormatLiteral " " #__VA_ARGS__))

#define NLOG(FormatLiteral, ...)  FLOG("","NSLog", FormatLiteral, ##__VA_ARGS__)

#else

#define FLOG(LogType, MacroType, FormatLiteral, ...)  NSLog (@"%s(%u): " LogType " \n" FormatLiteral "\n\n", __FUNCTION__, __LINE__, ##__VA_ARGS__);  

#define NLOG(FormatLiteral, ...)  FLOG("","NSLog", FormatLiteral, ##__VA_ARGS__) DO_PRAGMA(message (STR(__LINE__) " NSLog : " FormatLiteral " " #__VA_ARGS__))
#endif

The above code takes advantage of Diagnostics Pragmas (https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html) and a variadic macro (macro taking a variable number of args)

You can use the macros as in the following examples:

FIXME(Need to fix this bug in the next iteration)

CLOG(A simple constant string log message)

NSString *msg = @"My message";
NLOG("msg = %@",msg)

Note that the FIXME and CLOG macro instances require no quotes. The NLOG macro requires no @ string prefix, but does use quotes. None of the macros require a trailing semicolon.

If you want to use a macro for permanent logging without showing up in the Issue Navigator, you can create a project specific macro such as the following. Note how we leave off the DO_PRAGMA() after the FLOG() call:

#define PLOG_CORE_DATA(FormatLiteral, ...)  FLOG("PLOG_CORE_DATA","PLOG_CORE_DATA", FormatLiteral, ##__VA_ARGS__)

This will provide the power of NLOG to add function and line number to your log output, along with the ability to enable the macro to show up in the Issue Navigator if you wish (see next section).

To show all logging macros in the Issue Navigator (i.e. NLOG and project specific versions), set ENABLE_PRAGMA_FOR_FLOG prior to any of the header code above:

#define ENABLE_PRAGMA_FOR_FLOG 1

You will note that FLOG takes 2 arguments named LogType and MacroType. The first allows a project specific macro to add a prefix to the console output. The second is used when ENABLE_PRAGMA_FOR_FLOG is set to 1 to allow a project specific macro to specify a label for the Issue Navigator.

Swift temporary logging and FIXME markers

Swift does not use a preprocessor, so pragma flags and macros are not an option.

It is still possible though to provide similar functionality to the NLOG and FIXME macros used with Objective-C by making use of the benign warning "Treating a forced downcast as optional will never produce 'nil'"

I've created some code to do this available under the MIT license at: https://github.com/scottcarter/SNLog

Here is an example of the usage from the documentation for SNLog:

// Add a FIXME marker to Issue Navigator
g_fixme = g_anyFixme as SNLog.Fixme

// Log to console and add to Issue Navigator
g_log = SNLog.info("<message>") as SNLog

// Only log to console, but still add function and line number to output.
SNLog.info("<message>")

There are more usage cases shown on the SNLog GitHub page.

ios - How can I create bookmarks for temporary logging and FIXME marke...

ios objective-c swift navigation xcode6
Rectangle 27 3

I ran into a similar problem recently, and I do believe there's a solution.

The key idea is that there's a way to write a macro NUM_ARGS to count the number of arguments which a variadic macro is given. You can use a variation of NUM_ARGS to build NUM_ARGS_CEILING2, which can tell you whether a variadic macro is given 1 argument or 2-or-more arguments. Then you can write your Bar macro so that it uses NUM_ARGS_CEILING2 and CONCAT to send its arguments to one of two helper macros: one which expects exactly 1 argument, and another which expects a variable number of arguments greater than 1.

Here's an example where I use this trick to write the macro UNIMPLEMENTED, which is very similar to BAR:

/** 
 * A variadic macro which counts the number of arguments which it is
 * passed. Or, more precisely, it counts the number of commas which it is
 * passed, plus one.
 *
 * Danger: It can't count higher than 20. If it's given 0 arguments, then it
 * will evaluate to 1, rather than to 0.
 */

#define NUM_ARGS(...)                                                   \
    NUM_ARGS_COUNTER(__VA_ARGS__, 20, 19, 18, 17, 16, 15, 14, 13,       \
                     12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1)    

#define NUM_ARGS_COUNTER(a1, a2, a3, a4, a5, a6, a7,        \
                         a8, a9, a10, a11, a12, a13,        \
                         a14, a15, a16, a17, a18, a19, a20, \
                         N, ...)                            \
    N
/*
 * A variant of NUM_ARGS that evaluates to 1 if given 1 or 0 args, or
 * evaluates to 2 if given more than 1 arg. Behavior is nasty and undefined if
 * it's given more than 20 args.
 */

#define NUM_ARGS_CEIL2(...)                                           \
    NUM_ARGS_COUNTER(__VA_ARGS__, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, \
                     2, 2, 2, 2, 2, 2, 2, 1)
#define _UNIMPLEMENTED1(msg)                                        \
    log("My creator has forsaken me. %s:%s:%d." msg, __FILE__,      \
        __func__, __LINE__)

#define _UNIMPLEMENTED2(msg, ...)                                   \
    log("My creator has forsaken me. %s:%s:%d." msg, __FILE__,      \
        __func__, __LINE__, __VA_ARGS__)
#define UNIMPLEMENTED(...)                                              \
    CONCAT(_UNIMPLEMENTED, NUM_ARGS_CEIL2(__VA_ARGS__))(__VA_ARGS__)

Where CONCAT is implemented in the usual way. As a quick hint, if the above seems confusing: the goal of CONCAT there is to expand to another macro "call".

Note that NUM_ARGS itself isn't used. I just included it to illustrate the basic trick here. See Jens Gustedt's P99 blog for a nice treatment of it.

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.

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.

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.

c - Standard alternative to GCC's ##__VA_ARGS__ trick? - Stack Overflo...

c c99 c-preprocessor variadic-macros
Rectangle 27 3

I ran into a similar problem recently, and I do believe there's a solution.

The key idea is that there's a way to write a macro NUM_ARGS to count the number of arguments which a variadic macro is given. You can use a variation of NUM_ARGS to build NUM_ARGS_CEILING2, which can tell you whether a variadic macro is given 1 argument or 2-or-more arguments. Then you can write your Bar macro so that it uses NUM_ARGS_CEILING2 and CONCAT to send its arguments to one of two helper macros: one which expects exactly 1 argument, and another which expects a variable number of arguments greater than 1.

Here's an example where I use this trick to write the macro UNIMPLEMENTED, which is very similar to BAR:

/** 
 * A variadic macro which counts the number of arguments which it is
 * passed. Or, more precisely, it counts the number of commas which it is
 * passed, plus one.
 *
 * Danger: It can't count higher than 20. If it's given 0 arguments, then it
 * will evaluate to 1, rather than to 0.
 */

#define NUM_ARGS(...)                                                   \
    NUM_ARGS_COUNTER(__VA_ARGS__, 20, 19, 18, 17, 16, 15, 14, 13,       \
                     12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1)    

#define NUM_ARGS_COUNTER(a1, a2, a3, a4, a5, a6, a7,        \
                         a8, a9, a10, a11, a12, a13,        \
                         a14, a15, a16, a17, a18, a19, a20, \
                         N, ...)                            \
    N
/*
 * A variant of NUM_ARGS that evaluates to 1 if given 1 or 0 args, or
 * evaluates to 2 if given more than 1 arg. Behavior is nasty and undefined if
 * it's given more than 20 args.
 */

#define NUM_ARGS_CEIL2(...)                                           \
    NUM_ARGS_COUNTER(__VA_ARGS__, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, \
                     2, 2, 2, 2, 2, 2, 2, 1)
#define _UNIMPLEMENTED1(msg)                                        \
    log("My creator has forsaken me. %s:%s:%d." msg, __FILE__,      \
        __func__, __LINE__)

#define _UNIMPLEMENTED2(msg, ...)                                   \
    log("My creator has forsaken me. %s:%s:%d." msg, __FILE__,      \
        __func__, __LINE__, __VA_ARGS__)
#define UNIMPLEMENTED(...)                                              \
    CONCAT(_UNIMPLEMENTED, NUM_ARGS_CEIL2(__VA_ARGS__))(__VA_ARGS__)

Where CONCAT is implemented in the usual way. As a quick hint, if the above seems confusing: the goal of CONCAT there is to expand to another macro "call".

Note that NUM_ARGS itself isn't used. I just included it to illustrate the basic trick here. See Jens Gustedt's P99 blog for a nice treatment of it.

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.

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.

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.

c - Standard alternative to GCC's ##__VA_ARGS__ trick? - Stack Overflo...

c c99 c-preprocessor variadic-macros
Rectangle 27 3

A standalone approach that works for VC++, and breaks with GCC, is:

#define EXPAND(...) __VA_ARGS__
#define LPAREN (
#define RPAREN )
x(__VA_ARGS__)
EXPAND(x LPAREN __VA_ARGS__ RPAREN)

You should be able to combine the two forms to put the compiler-specific bits in a single place.

Note though that there cannot be a standard C++ answer: you rely on x() being a macro invocation with no arguments. That's not how the preprocessor works in standard C++: if x is a variadic macro, x() invokes the macro with a single argument, and that single argument is empty. Additionally, you rely on being able to omit the variadic arguments: standard C++ also doesn't allow that. If a macro is defined as #define FOO(x,...), invoking it as FOO(1) is invalid. As there cannot be a standard approach, hopefully it is less of a problem for you that the various approaches will necessarily be compiler-specific.

c++ - VC++ vs GCC preprocessor - Stack Overflow

c++ gcc visual-c++ macros c-preprocessor
Rectangle 27 4

You can use the NARGS macro, which counts the arguments of variadic macros, to create recursive macros that apply a prefix to all your aguments:

#define NARGS(...) NARGS_(__VA_ARGS__, 5, 4, 3, 2, 1, 0)
#define NARGS_(_5, _4, _3, _2, _1, N, ...) N

#define CONC(A, B) CONC_(A, B)
#define CONC_(A, B) A##B

#define PREFIX_0(P, E) E
#define PREFIX_1(P, E) P:E
#define PREFIX_2(P, E, ...) P:E PREFIX_1(P, __VA_ARGS__)
#define PREFIX_3(P, E, ...) P:E PREFIX_2(P, __VA_ARGS__)
#define PREFIX_4(P, E, ...) P:E PREFIX_3(P, __VA_ARGS__)
#define PREFIX_5(P, E, ...) P:E PREFIX_4(P, __VA_ARGS__)

#define PREFIX(P, ...) CONC(PREFIX_, NARGS(__VA_ARGS__)) (P, __VA_ARGS__)

PREFIX(F, A)
PREFIX(F, A, B, C, D)

Here, the total number of arguments is limited to 5 for brevity, but you can extend this solution by extending the NARGS and NARGS_ in the obvious way and by writing more PREFIX_X macros.

Thanks! Though I was originally hoping to implement without Boost.PP, it seems like it would probably be worth the trouble to include the dependency. This is a great solution, but might get a bit out of control in my use case. Thanks again!

c++ - Distributing an argument in a variadic macro - Stack Overflow

c++ c c-preprocessor variadic-macros
Rectangle 27 15

Jeff Walden's answer works and all, but you have to declare FOO_CHOOSE_HELPER/1/2 for each FOO macro you want to have variadic arguments. I have developed a layer of abstraction to solve this issue. Consider the following:

#define GLUE(x, y) x y

#define RETURN_ARG_COUNT(_1_, _2_, _3_, _4_, _5_, count, ...) count
#define EXPAND_ARGS(args) RETURN_ARG_COUNT args
#define COUNT_ARGS_MAX5(...) EXPAND_ARGS((__VA_ARGS__, 5, 4, 3, 2, 1, 0))

#define OVERLOAD_MACRO2(name, count) name##count
#define OVERLOAD_MACRO1(name, count) OVERLOAD_MACRO2(name, count)
#define OVERLOAD_MACRO(name, count) OVERLOAD_MACRO1(name, count)

#define CALL_OVERLOAD(name, ...) GLUE(OVERLOAD_MACRO(name, COUNT_ARGS_MAX5(__VA_ARGS__)), (__VA_ARGS__))

With this architecture you can define variadic macros as such:

With Jeff's answer you would have to define the macros as follows:

#define ERROR1(title) printf("Error: %s\n", title)
#define ERROR2(title, message)\
    ERROR1(title);\
    printf("Message: %s\n", message)

#define ERROR_CHOOSE_HELPER2(count) ERROR##count
#define ERROR_CHOOSE_HELPER1(count) ERROR_CHOOSE_HELPER2(count)
#define ERROR_CHOOSE_HELPER(count) ERROR_CHOOSE_HELPER1(count)

#define ERROR(...) GLUE(ERROR_CHOOSE_HELPER(COUNT_ARGS_MAX5(__VA_ARGS__)),\
    (__VA_ARGS__))

#define ASSERT1(expr) singleArgumentExpansion(expr)
#define ASSERT2(expr, explain) twoArgumentExpansion(expr, explain)

#define ASSERT_CHOOSE_HELPER2(count) ASSERT##count
#define ASSERT_CHOOSE_HELPER1(count) ASSERT_CHOOSE_HELPER2(count)
#define ASSERT_CHOOSE_HELPER(count) ASSERT_CHOOSE_HELPER1(count)

#define ASSERT(...) GLUE(ASSERT_CHOOSE_HELPER(COUNT_ARGS_MAX5(__VA_ARGS__)),\
    (__VA_ARGS__))

It's not a big deal, however I like my code to be as concise as possible. It also helps exponentially, if you are using several variadic macros, to reduce code duplication and the complications that can cause. As far as I know, this method is also portable. I have tested it on many of the most common compilers and they produced the same results.

int foo()
{
    ASSERT(one); // singleArgumentExpansion(one)
    ASSERT(two, "foopy"); // twoArgumentExpansion(two, "foopy")

    ERROR("Only print a title");
    ERROR("Error title", "Extended error description");
}
#define CALL_OVERLOAD
error: expected ')' before ';' token

Based on this, heres an example that uses up to 16 args to implement a var-args based ELEM macro, stackoverflow.com/a/24837037/432509 (may be of interest)

Since this answer is IMHO the best so far, probably its worth noting that its (fairly) portable too, that it works with MSVC, GCC, Clang (didn't check Intel yet). (not only MSVC)

c++ - MSVC++ variadic macro expansion - Stack Overflow

c++ visual-c++ c-preprocessor variadic-macros
Rectangle 27 5

#include <boost/preprocessor/seq/for_each.hpp>
#include <boost/preprocessor/variadic/to_seq.hpp>

#define TRANSFORM(r, data, elem) data:elem

#define MACRO(F, ...) \
    BOOST_PP_SEQ_FOR_EACH(TRANSFORM, F, BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__))

Thanks, this really simplifies the code! One question though: if the first element is actually a fixed-length tuple rather than a single element, how do I unpack it within TRANSFORM? Meaning, I'd like MACRO((FX,FY), A, B) to result in FX_FY:A FX_FY:B but the unpacking is not working as expected. (Sorry, I'm new to Boost.PP) Thanks!

So you want to concatenate all elements in a tuple with _ and pass that as the argument to F?

Yeah - I use that as example, but I'd like to be able to expand the "data" tuple and pass its elements into another macro that would format an identifier... along the lines of concatenating them with '_' separators. The contents of the "data" tuple would always have a fixed number of elements.

Yes, but I need to be able to format it in two different ways... The full result I'm hoping to achieve is: Call: MACRO( (F1,F2,F3), (A1,A2), (B1,B2) ) Result: { F1_F2_F3<A1,A2>::F1_F3 } { F1_F2_F3<B1,B2>::F1_F3 } The idea being that I'm using (F1,F2,F3) as something of a parameter pack to format various identifiers for each of the subsequent pairs - (A1,A2), etc - to which it is applied. Thanks very much for your help!

c++ - Distributing an argument in a variadic macro - Stack Overflow

c++ c c-preprocessor variadic-macros
Rectangle 27 2

One way to do it is to use a FOR_EACH macro on __VA_ARGS__, its not pretty and it probably takes a while to fully follow along with whats happening but at least it doesn't depend on boost.

// Concatenates tokens, even when the tokens are macros themselves.
#define PP_JOIN_HELPER_HELPER(_0, _1)       _0##_1
#define PP_JOIN_HELPER(_0, _1)              PP_JOIN_HELPER_HELPER(_0, _1)
#define PP_JOIN_IMPL(_0, _1)                PP_JOIN_HELPER(_0, _1)

#define PP_JOIN_2(_0, _1)                                                                   PP_JOIN_IMPL(_0, _1)
#define PP_JOIN_3(_0, _1, _2)                                                               PP_JOIN_2(PP_JOIN_2(_0, _1), _2)
#define PP_JOIN_4(_0, _1, _2, _3)                                                           PP_JOIN_2(PP_JOIN_3(_0, _1, _2), _3)
#define PP_JOIN_5(_0, _1, _2, _3, _4)                                                       PP_JOIN_2(PP_JOIN_4(_0, _1, _2, _3), _4)
#define PP_JOIN_6(_0, _1, _2, _3, _4, _5)                                                   PP_JOIN_2(PP_JOIN_5(_0, _1, _2, _3, _4), _5)
#define PP_JOIN_7(_0, _1, _2, _3, _4, _5, _6)                                               PP_JOIN_2(PP_JOIN_6(_0, _1, _2, _3, _4, _5), _6)
#define PP_JOIN_8(_0, _1, _2, _3, _4, _5, _6, _7)                                           PP_JOIN_2(PP_JOIN_7(_0, _1, _2, _3, _4, _5, _6), _7)
#define PP_JOIN_9(_0, _1, _2, _3, _4, _5, _6, _7, _8)                                       PP_JOIN_2(PP_JOIN_8(_0, _1, _2, _3, _4, _5, _6, _7), _8)
#define PP_JOIN_10(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9)                                  PP_JOIN_2(PP_JOIN_9(_0, _1, _2, _3, _4, _5, _6, _7, _8), _9)
#define PP_JOIN_11(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10)                             PP_JOIN_2(PP_JOIN_10(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9), _10)
#define PP_JOIN_12(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11)                        PP_JOIN_2(PP_JOIN_11(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10), _11)
#define PP_JOIN_13(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12)                   PP_JOIN_2(PP_JOIN_12(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11), _12)
#define PP_JOIN_14(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13)              PP_JOIN_2(PP_JOIN_13(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12), _13)
#define PP_JOIN_15(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14)         PP_JOIN_2(PP_JOIN_14(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13), _14)
#define PP_JOIN_16(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15)    PP_JOIN_2(PP_JOIN_15(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14), _15)

// Chooses a value based on a condition.
#define PP_IF_0(t, f)           f
#define PP_IF_1(t, f)           t
#define PP_IF(cond, t, f)       PP_JOIN_2(PP_IF_, PP_TO_BOOL(cond))(t, f)

// Converts a condition into a boolean 0 (=false) or 1 (=true).
#define PP_TO_BOOL_0 0
#define PP_TO_BOOL_1 1
#define PP_TO_BOOL_2 1
#define PP_TO_BOOL_3 1
#define PP_TO_BOOL_4 1
#define PP_TO_BOOL_5 1
#define PP_TO_BOOL_6 1
#define PP_TO_BOOL_7 1
#define PP_TO_BOOL_8 1
#define PP_TO_BOOL_9 1
#define PP_TO_BOOL_10 1
#define PP_TO_BOOL_11 1
#define PP_TO_BOOL_12 1
#define PP_TO_BOOL_13 1
#define PP_TO_BOOL_14 1
#define PP_TO_BOOL_15 1
#define PP_TO_BOOL_16 1

#define PP_TO_BOOL(x)       PP_JOIN_2(PP_TO_BOOL_, x)

// Returns 1 if the arguments to the variadic macro are separated by a comma, 0 otherwise.
#define PP_HAS_COMMA(...)                           PP_HAS_COMMA_EVAL(PP_HAS_COMMA_ARGS(__VA_ARGS__, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0))
#define PP_HAS_COMMA_EVAL(...)                      __VA_ARGS__
#define PP_HAS_COMMA_ARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, ...) _16

// Returns 1 if the argument list to the variadic macro is empty, 0 otherwise.
#define PP_IS_EMPTY(...)                                                        \
    PP_HAS_COMMA                                                                \
    (                                                                           \
        PP_JOIN_5                                                           \
        (                                                                       \
            PP_IS_EMPTY_CASE_,                                              \
            PP_HAS_COMMA(__VA_ARGS__),                                      \
            PP_HAS_COMMA(PP_IS_EMPTY_BRACKET_TEST __VA_ARGS__),         \
            PP_HAS_COMMA(__VA_ARGS__ (~)),                                  \
            PP_HAS_COMMA(PP_IS_EMPTY_BRACKET_TEST __VA_ARGS__ (~))      \
        )                                                                       \
    )

#define PP_IS_EMPTY_CASE_0001           ,
#define PP_IS_EMPTY_BRACKET_TEST(...)   ,

// Retrieve the number of arguments handed to a variable-argument macro.
#define PP_VA_NUM_ARGS_HELPER(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, N, ...)    N
#define PP_VA_NUM_ARGS(...) PP_VA_NUM_ARGS_HELPER(__VA_ARGS__, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1)

// Correctly handles the case of 0 arguments.
#define PP_NUM_ARGS(...)        PP_IF(PP_IS_EMPTY(__VA_ARGS__), 0, PP_VA_NUM_ARGS(__VA_ARGS__))

// Pass each variable in a VA_ARGS list to a macro.
#define PP_FE_0(action, X)
#define PP_FE_1(action, X) action(X)
#define PP_FE_2(action, X, ...) action(X)PP_FE_1(action, __VA_ARGS__)
#define PP_FE_3(action, X, ...) action(X)PP_FE_2(action, __VA_ARGS__)
#define PP_FE_4(action, X, ...) action(X)PP_FE_3(action, __VA_ARGS__)
#define PP_FE_5(action, X, ...) action(X)PP_FE_4(action, __VA_ARGS__)
#define PP_FE_6(action, X, ...) action(X)PP_FE_5(action, __VA_ARGS__)
#define PP_FE_7(action, X, ...) action(X)PP_FE_6(action, __VA_ARGS__)
#define PP_FE_8(action, X, ...) action(X)PP_FE_7(action, __VA_ARGS__)
#define PP_FE_9(action, X, ...) action(X)PP_FE_8(action, __VA_ARGS__)
#define PP_FE_10(action, X, ...) action(X)PP_FE_9(action, __VA_ARGS__)
#define PP_FE_11(action, X, ...) action(X)PP_FE_10(action, __VA_ARGS__)
#define PP_FE_12(action, X, ...) action(X)PP_FE_11(action, __VA_ARGS__)
#define PP_FE_13(action, X, ...) action(X)PP_FE_12(action, __VA_ARGS__)
#define PP_FE_14(action, X, ...) action(X)PP_FE_13(action, __VA_ARGS__)
#define PP_FE_15(action, X, ...) action(X)PP_FE_14(action, __VA_ARGS__)
#define PP_FE_16(action, X, ...) action(X)PP_FE_15(action, __VA_ARGS__)

#define PP_FOR_EACH(action, ...) PP_JOIN_2(PP_FE_, PP_NUM_ARGS(__VA_ARGS__))(action, __VA_ARGS__)

Definition for your macro:

#define CREATE_VAR(var)     double var{smc::define_variable(data, var, #var)};
#define CREATE_VARS(...)    PP_FOR_EACH(CREATE_VAR, __VA_ARGS__)

Also, you may or may not need to use #pragma GCC system_header depending on what warning lvl you're compiling with in order to get rid of ISO C99 requires rest arguments to be used. You could've used #pragma GCC diagnostic ignored "-pedantic-errors" but apparently that is bugged. If you're using msvc you'll have to figure out the warning to disable by yourself.

Nice Code. Did you make this yourself? I don;t know yet if my code will be boost independent atm but if it will this will definitely come in handy. Sorry I can't accept this answer, at the moment @angew came first and is short and sweet - currently works for me. Thanks for the alternative for myself and everyone else to see. Appreciate it.

@woosah Its mostly a cleaned up version of a piece of code I found on altdevblogaday. I personally prefer going boost free. You could simply create a file pp.h and include it in the files where you need such FOR_EACH and JOIN macro helpers. Its always better to not depend on external libraries when possible.

C++ and preprocessor macros: variadic type - Stack Overflow

c++ macros variadic preprocessor-directive