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 14:53:47

On Mon, 14 Nov 2011 10:57:27 +0000, Gennadiy Rozental wrote:

> As for scaling I am not sure what you mean. Would you care to show an
> example?

Here's the list that I gave Eric when he asked me previously in regards to 
variadic templates, but really these are true for all forms of variadics.

1) If forces a particular argument order.  It either tends to break 
symmetries or tends to require argument orders to change on many things.  
I.e. not only is the argument order forced for the variadic interface, it 
tends to be viral and therefore a maintenance disaster.

2) It does not play well with overloading (via number of arguments with 
macros, specialization of templates, or function overloading).

3) It frequently destroys the ability to use default arguments.

4) It does not work when multiple data structures need to be passed.

5) It removes the ability to use the single variadic data for other stuff.

6) Non-delimited data structures such as this cannot nest.

7) In the particular context of macros, it cannot contain elements that 
contain "open" commas such as class template instantiations with multiple 
arguments.  Currently, sequences in the pp-lib cannot do this either, but 
that is the result of their current definition.  Non-unary sequences (such 
as (a, b)(c, d)(e, f)) can be specified and truly variadic sequences (such 
as (a)(b, c)(d, e, f)) can also be specified (the difference relates to 
the way that the "elements" of the sequence need to be passed on to other 
macros).

The best ways that variadics can be used is for initialization of some 
kind or for "functions" that have no depth (i.e. do not rely on other 
variadic public or private interfaces--e.g. things like min and max).  
Variadics can also be used effectively as a mechanism to pass "opaque" 
argument sets through other algorithms or through other functions (e.g. 
perfect forwarding).  Of particular note in this latter case is that the 
actual (ultimate) target of those arguments is not variadic which implies 
that from a user standpoint, it outer interface isn't truly variadic only 
certain numbers and types of arguments will usually work.  The effect is 
simply an implementation mechanism to forward to an overload set without 
replicating the overload set.  This has slightly less context in C++11 due 
to lambdas' ability to easily encode such information directly.

Regards,
Paul Mensonides