Boost logo

Boost :

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

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at