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