Hendrik Schober <> writes:
> wrote:
>> On Oct 31, 10:56 am, Hendrik Schober <spamt...@gmx.de> wrote:
>>> Keith Thompson wrote:
>>>> Hendrik Schober <spamt...@gmx.de> writes:
>>>>> Keith Thompson wrote:
>>>>>> "robertwess...@yahoo.com" <robertwess...@yahoo.com> writes:
>>>>>>> Frankly I think ranges on the case constant expressions would be a
>>>>>>> more useful addition while staying with the basic philosophy of the C
>>>>>>> switch statement. IOW, "case 2...5:", or something along those
>>>>>>> lines. But still not something I'm loosing sleep over...
>>>>>> Then programmers will inevitably write
>>>>>> case 'A' ... 'Z':
>>>>>> which is non-portable (under EBCDIC it matches '\' and '}').
>>>>> And why exactly would that be worse than an 'if'-'else' chain
>>>>> relying on ASCII?
>>>> It wouldn't. [...]
>>> Then I don't see how your above argument is valid.
>> [...]
>> My interprentation:
>> He says that adding such syntax, .., would introduce more newbie
>> pitfalls in the language, because most people would expect 'A' .. 'Z'
>> to mean all the uppercase letters, where it could mean anything.
>
> And wouldn't those be the people who now use 'if' to
> do exactly the same?
Probably. But my point, one more time, is that this feature would, in
this particular case, make it *easier* to write bad code (i.e., code
that assumes 'A'-'Z' are contiguous) without making it any easier to
wrote good code (i.e., code that avoids that assumption by using
isupper(), which can't be used in a case expression).
Suppose you're maintaining some code that uses
case 'A' ... 'Z':
and you want to make it more general. You'll have to restructure the
code, using an if statement rather than a switch statement.
On the other hand, if the code you're maintaining uses the equally
non-portable:
if ('A' <= c && c <= 'Z') ...
then it's much more straightforward to change it to:
if (isupper(c)) ...
or perhaps
if (isupper((unsigned char)c)) ...
I'm not saying this is an ironclad argument against adding such a
feature, just that it's a (possibly) significant issue that should be
considered.
>> My view on it: Syntactic sugar that would only complicate the
>> language(s) further without being a real convenience.
On the other hand, it *could* be a real convenience when you need
numeric ranges. It would also be perfectly ok for '0' ... '9', or
even for 'A' ... 'Z' if portability isn't a high priority.
> I'm not a string proponent of the feature. I just don't
> see the validity of this argument against this.
> Any feature added to the language will open new ways to
> abusing. If that by itself was an argument against new
> features, we wouldn't have had any features at all.
Sure, any feature can be abused; the problem is that this feature
makes certain kinds of abuse easier without making the corresponding
non-abuse any easier.
--
Keith Thompson (The_Other_Keith)
kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Similar Threads
