Subject: Re: [boost] Need for BOOST_PP_VARIADIC_POP_FRONT
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2011-11-13 12:47:41
Edward Diener <eldiener <at> tropicsoft.com> writes:
> On 11/13/2011 11:05 AM, Gennadiy Rozental wrote:
> > Paul Mensonides<pmenso57<at> comcast.net> writes:
> >> Variadic data is not a true data structure and should not be supported as
> >> such. Therefore, it should not have a POP_FRONT, for example. Convert it
> >> into a real data structure (such as a sequence) and then do your
> >> processing on that data structure.
> > How would it help me if I want to take first arguments from __VA_ARGS__
> > and pass the rest to the different variadic macro?
> First I would say that it would be better internally to pass a PP
> sequence to your different macro rather than variadic data.
And what if the second macro is part of public interface as well?
> But if you want to do it the way you say above, just convert the
> variadic data to a PP sequnce using BOOST_PP_VARIADIC_TO_SEQ, pop the
> first element from the sequence using BOOST_PP_SEQ_POP_FRONT, convert
> the sequence back to variadic data using BOOST_PP_SEQ_ENUM, and pass
> that data as your variadic data.
That's good. Why not wrap it all into a simple macro that does it all?
> In my VMD library and the work I did with Paul in adding variadic data
> to the preprocessor code on the trunk, I always mentioned that I viewed
> C++ variadic data as an easier to use interface for end-users but that
> Boost PP has much richer data types internally.
That's the core issue: variadic data provides better interface. And do not see
why we should discourage use of it. I believe it should be supported completely
with all the necessary interfaces. Internally we should be free to convert back
and forth between variadic data and PP data structures, but it's implementation
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk