Re: [boost] [preprocessor] Warning: Incoming

Subject: Re: [boost] [preprocessor] Warning: Incoming
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2011-07-01 21:29:39

On Fri, 01 Jul 2011 20:13:19 -0400, Edward Diener wrote:

> I agree that using variadic argument lists as opposed to a data
> structure containing the data ( list, vector, etc. ) is a poor way to
> design in general. But sometimes one creates interfaces with which
> programmers are more comfortable just for the sake of end-user ease.
> This goes back discussions about variadic data in macros being a more
> natural way of passing data to macros than pp-lib data structures. When
> i created VMD, and subsequently worked with you to add variadic data to
> pp-lib, I was always quick to acknowledge that my main reason for doing
> so was almost entirely to satisfy end-user expectations of the way macro
> parameters are normally passed. Other than that variadic data in macros
> holds no advantage to pp-lib data structures and can generally be
> ignored.
> 
> In the same way a designer may decide to create fairly simple
> functionality using variadic argument lists, just to satsfy end-user
> programmer expectations. While in the vast majority of cases it should
> be avoided for all the reasons you give above, and mostly because it is
> just a poor way of designing software of any complexity.

And my response is the same as always: the ease-of-use argument is a red 
herring.  End user expectations are often misguided, and doing something 
wrong, on purpose, to fulfill those expectations is bad design and simply 
perpetuates misguided expectations.  Input via pp-lib sequence is 
insignificantly different in terms of number of typed characters.  The 
difference is typically two parentheses--one at the beginning and one at 
the end (", " is the same number of characters as ")(").  Same thing for 
tuples.  Further, it isn't particularly more or less readable--unless the 
user has no idea that they are writing code in a different language--
which is the real problem.  Perpetual hand-holding perpetuates the 
problem.  A prerequisite of a writing in a language is knowledge of 
*what* language one is writing.  Things that intentionally hide the fact 
that a different language is being used simply perpetuate the underlying 
problem of users thinking that the there aren't two languages (that have 
drastically different semantics).  The solution is not hand-holding, it's 
education--education which won't happen while the hand-holding persists.

That is not to say that initialization by way of variadics is in and of 
itself good or bad.  Rather it's the *motivation* to make it look like 
the underlying language that is bad, and this particular ease-of-use 
argument falls into that category.  There may well be other motivations 
that select one form of input over another--including variadics.  As an 
example, let's say there is a macro that takes a sequence of types and 
does something with each, but also uses the entire thing as a whole 
without processing.  E.g.

#define MACRO(...) \
    /* do stuff for each "element" of __VA_ARGS__ */ \
    std::tuple<__VA_ARGS__> xyz; \
    /**/

Here there is a potentially compelling reason to use the __VA_ARGS__ 
directly.  Otherwise, you'd have to convert the input data structure to a 
comma-separated list of types to pass to the tuple template.  A 
motivation along these lines is potentially valid, but that's not because 
a ill-conceived argument based on ease-of-use (not that all ease-of-use-
arguments are ill-conceived), but because of a ease-of-implementation 
argument.

Regards,
Paul Mensonides