From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2004-11-13 19:46:13
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Daniel James
> Paul Mensonides wrote:
> >>1. Use of PP_SEQ interface to "parse" function name and arguments
> >>
> >> int X::foo(char* buf, size_t len)
> >> {
> >> BOOST_TRACE_MEM_FUN( (foo)(buf, len) );
> >
> > ^^^^^^^^
> >
> > You can't do this without variadic macros (ala C99). We
> should have
> > these in
> > C++ eventually, but we don't right now and the pp-lib
> doesn't support them.
>
> I think he's just using BOOST_PP_SEQ_TAIL to get the
> arguments. This means that they're never directly accessed by
> the sequence macros.
SEQ_TAIL *is* a sequence macro.
> For
> example:
>
> #define ARGUMENT_STRING(fn)
> BOOST_PP_STRINGIZE(BOOST_PP_SEQ_TAIL(fn))
>
> ARGUMENT_STRING((foo)(buf, len)) // Expands to "(buf, len)"
>
> That works on g++, although I don't know how portable it is.
It works because of a poorly-designed gcc extension. It shouldn't. The only
thing that you can do with a sequence that contains a non-unary element is
process the elements before it. You cannot touch it in any way; you cannot even
test whether or not it is non-unary. In the case of SEQ_TAIL, it has to go
through the non-unary element to tell where the end is which should result in
the wrong number of arguments (2) to a macro (which takes 1).
Even with variadics, it should *still* be an error because the library isn't
currently designed to handle it. (I.e. there is not a single instance of ... in
any parameter list of any macro in the entire library.)
Regards,
Paul Mensonides