Re: [boost] Need for BOOST_PP_VARIADIC_POP_FRONT

Subject: Re: [boost] Need for BOOST_PP_VARIADIC_POP_FRONT
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2011-11-14 02:50:17

On Mon, 14 Nov 2011 04:49:47 +0000, Gennadiy Rozental wrote:

> Edward Diener <eldiener <at> tropicsoft.com> writes:
> 
>> > That's good. Why not wrap it all into a simple macro that does it
>> > all?
>> 
>> Because I would only be duplicating endless functionality which the
>> other Boost PP data types already have.
> 
> We duplicating functionality for 4 different data types already.

Yes, and only two of them are good, sequences and tuples.  Of those two, 
tuples are only good for small (usually disjoint) data sets.  Sequences 
are far superior in most respects.

In fact, if the pp-lib had real variadic support, tuple usage almost goes 
away completely.  This is due to the single largest type of tuple usage--
passing multiple pieces of auxiliary information through higher order 
algorithms and then decoding it via TUPLE_ELEM.  With real variadic 
support, algorithms such as (e.g.) REPEAT which is currently defined as 
REPEAT(count, macro, data) would be altered to be REPEAT(count, 
macro, ...).  Similarly, SEQ_FOR_EACH which is currently defined as 
SEQ_FOR_EACH(macro, data, seq) would be altered to be SEQ_FOR_EACH(macro, 
seq, ...).  Doing this drastically decreases TUPLE_ELEM clutter.

>> I agree that it provides an easier to use interface for the end user.
>> But I strongly disagree that it is a better interface than the other
>> Boost PP data types.
> 
> I feel like we are playing with the words. If you have an option to
> provide interface like this:
> 
> FOO((a)(b)(c))
> 
> or this:
> 
> FOO( a, b, c )
> 
> which one would you prefer, find easier, more convenient, better?

The first one is better, they are both just as easy, and the latter is 
more convenient depending on the types of data.  The problem with the 
second one is that it doesn't scale--just like passing around variadic 
data via variadic templates (with or without perfect forwarding) doesn't 
scale.

> I expect variadic based interfaces to become quite popular in near
> future and eventually prevail over any other kinds of macro based
> interfaces (in cases where one truly want variable number of macro
> arguments).

That may be true for trivial user interfaces.  It won't be true for a 
heavy-duty preprocessor metaprogramming library because it is misguided 
and doesn't scale.  Good is not defined by the popularity.

> Boost PP library should treat it like a first class citizen as well.
> Internally we might want to convert variadic data in a different
> collection type to perform some advanced data massaging, but not always

No.  First-class support for variadics in the pp-lib would not take this 
form, and it wouldn't take this form even if other, better uses of 
variadic data didn't exist.  Variadic data is not a good data structure 
and doesn't scale.

Regards,
Paul Mensonides