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