Boost logo

Boost :

Subject: Re: [boost] Alternative implementation for BOOST_PP_VARIADIC_SIZE
From: Jens Gustedt (jens.gustedt_at_[hidden])
Date: 2011-11-16 04:26:51

Edward Diener <eldiener <at>> writes:

> I admit I do not understand how this can be. in the expansion to the
> code on that page it sure looks to me like
> 'HAS_COMMA(_TRIGGER_PARENTHESIS_ __VA_ARGS__ (~))' will equate to 1 when
> __VA_ARGS__ = AMACRO since 'AMACRO (~)' = '()', '_TRIGGER_PARENTHESIS_
> ()' = ',', and HAS_COMMA(,) = 1.

No your analysis is not correct. When the argument to HAS_COMMA is
parsed, here, a substitution of the arguments of the surrounding macro
replacement has already taken place. So as it is processed we have


So now, when the arguments for HAS_COMMA are parsed
_TRIGGER_PARENTHESIS_ is not followed by a '(' token, and so macro
replacement for _TRIGGER_PARENTHESIS_ doesn't take place.

Whatever the result of expanding the rest of the argument "AMACRO (~)"
is _TRIGGER_PARENTHESIS_ *must* not be considered again.

So the result of the argument expansion here is the token sequence
which then is passed to HAS_COMMA for substitution.

> On 11/13/2011 9:48 PM, Gennadiy Rozental wrote:
> > On the other hand if you define it like this:
> >
> > #define AMACRO(x,y) anything here
> >
> > if fails to build.
> >
> > In any case, as I said previous, this is corner case we should just

Yes, I see, this is certainly a corner case that doesn't work.

When thinking of it now, with the argument above I found another one
that doesn't work which is

#define BMACRO() whatever

because of the "(~)" in the tests. But that can simply be repaired by
putting "()" there instead, I think.


Boost list run by bdawes at, gregod at, cpdaniel at, john at