5

I was looking at "How to properly use references with variadic templates," and wondered how far comma expansion can go.

Here's a variant of the answer:

inline void inc() { }

template<typename T,typename ...Args>
inline void inc(T& t, Args& ...args) { ++t; inc(args...); }

Since variadic arguments are expanded to a comma-separated list of their elements, are those commas semantically equivalent to template/function-argument separators, or are they inserted lexically, making them suitable for any (post-preprocessor) use, including the comma operator?

This works on my GCC-4.6:

// Use the same zero-argument "inc"

template<typename T,typename ...Args>
inline void inc(T& t, Args& ...args) { ++t, inc(args...); }

But when I tried:

// Use the same zero-argument "inc"

template<typename T,typename ...Args>
inline void inc(T& t, Args& ...args) { ++t, ++args...; }

I kept getting parsing errors, expecting the ";" before the "...", and that "args" won't get its pack expanded. Why doesn't it work? Is it because if "args" is empty, we get an invalid blob of punctuation? Is it legal, and my compiler isn't good enough?

(I've tried surrounding "args" in parentheses, and/or use post-increment; neither worked.)

Community
  • 1
  • 1
CTMacUser
  • 1,842
  • 1
  • 15
  • 22

1 Answers1

6

Unpacking is only allowed in certain contexts, and comma separated statements doesn't belong to them. Using your words: The expansion is semantically and not lexically. However, it doesn't matter because there are several other ways of doing it. There are already some kind of patterns/idioms to write simple variadic functions. One way of doing it:

Use a helper template function, that does nothing at all:

template <typename ...Args>
void pass(Args&&...) { }

Instead of using the comma operator, pass the expressions to this function:

template <typename ...Args>
void inc(Args&&... args)
{
    pass(++std::forward<Args>(args)...);
}

You can use the comma operator within the expansion, if the expressions have to be more complex. This might be useful in your case, if some operator++ have return type void:

    pass((++std::forward<Args>(args), 0)...);
nosid
  • 45,370
  • 13
  • 104
  • 134
  • 3
    This answer is wrong (i.e. dangerous to use). The order of argument evaluation is undefined, so the order of side effects is undefined too. It should be a `template void pass(T)` function, taking an `initializer_list` as its argument: `pass({(something)...})`. http://stackoverflow.com/questions/621542/compilers-and-argument-order-of-evaluation-in-c – polkovnikov.ph Oct 18 '15 at 23:56
  • 1
    @polkovnikov.ph: Well, I wouldn't call it _wrong_. It is as correct or wrong as every function call with arguments with side effects. But you are right. There are alternatives with defined evaluation order. However, I would recommend _brace initialisation_ of a class with a variadic constructor over `std::initializer_list`. – nosid Oct 19 '15 at 20:56
  • Ahh, but what if you want to do `args.foo()...` where `foo` returns `void`? – Qwertie Feb 28 '19 at 19:28