Subject: Re: [boost] [preprocessor] Warning: Incoming
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2011-07-01 23:29:20
On Sat, 02 Jul 2011 01:39:38 +0000, Nathan Ridge wrote:
>> 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
>> ")(").
>
> As a pp-lib user, I find it much more cumbersome to write
> "MY_MACRO((a)(b)(c))" than "MY_MACRO(a, b, c)" - primarily because the
> latter requires a lot less keyboard acrobatics - and I have written my
> own equivalent of VARIADIC_TO_SEQ to allow me to write the latter.
Keyboard acrobatics? I thought programmers were the last of the breed
that could type all of those special characters without evening thinking
about it. :) In any case, I'd bet that this has a lot more to do with
familiarity (even muscle familiarity) than it does with acrobatics. I do
both all of the time and because I'm used to both, the difference in
keystrokes is irrelevant. Further, it is much easier to work with
sequences in debugging contexts because it is easier to compose them and
(slightly) easier remove elements (actually removing or via comments).
E.g.
#define A (1)(2)(3)
#ifndef NDEBUG
#define B (4)(5)(6)
#else
#define B
#endif
MY_MACRO(A B)
What do you do with sequences of C++ types which may contain open
commas? The bottom line is that MY_MACRO(a, b, c) does not scale to the
general case. Neither does MY_MACRO((a, b, c)), though it gets closer
(though not for C++ types). The pp-lib has to provide infrastructure to
support the general case, not a bunch of highly specialized cases.
Regards,
Paul Mensonides