C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression"

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: C/C++ language proposal: Change the 'case expression' from"integ ral constant-expression&quot ; to "integr al expression&quot ;

On Thu, 30 Oct 2008 12:05:18 -0700, Keith Thompson wrote:

Harald van Dijk <truedfx@gmail. comwrites:

>On Wed, 29 Oct 2008 13:45:46 -0700, Keith Thompson wrote:

>>Caveat: Sometimes ('A' <= c && c <= 'Z') *is* exactly what you want,
>>if you're writing deliberately non-portable code.

>>
>It doesn't need to be *deliberately* non-portable. If you were
>implementing your own C library, on an ASCII-based machine with minimal
>locale support, this could be the best way to write isupper.

>
I'd call that deliberately non-portable, at least if you know what
you're doing.

I read your message as suggesting non-portable had to be a goal for 'A'<=c
&& c<='Z' to be the right thing. If you meant that non-portable can be
okay, just that you need to be aware of it, then agreed.

[Pete Becker]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

On 2008-10-30 14:49:12 -0400, Harald van Dijk <truedfx@gmail. comsaid:

On Wed, 29 Oct 2008 13:45:46 -0700, Keith Thompson wrote:

>Caveat: Sometimes ('A' <= c && c <= 'Z') *is* exactly what you want, if
>you're writing deliberately non-portable code.

>
It doesn't need to be *deliberately* non-portable. If you were
implementing your own C library, on an ASCII-based machine with minimal
locale support, this could be the best way to write isupper.

Probably not. A table of flags is best, because it handles all the
isxxx functions.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Keith Thompson]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

Harald van Dijk <truedfx@gmail. comwrites:

On Thu, 30 Oct 2008 12:05:18 -0700, Keith Thompson wrote:

>Harald van Dijk <truedfx@gmail. comwrites:

>>On Wed, 29 Oct 2008 13:45:46 -0700, Keith Thompson wrote:
>>>Caveat: Sometimes ('A' <= c && c <= 'Z') *is* exactly what you want,
>>>if you're writing deliberately non-portable code.
>>>
>>It doesn't need to be *deliberately* non-portable. If you were
>>implementin g your own C library, on an ASCII-based machine with minimal
>>locale support, this could be the best way to write isupper.

>>
>I'd call that deliberately non-portable, at least if you know what
>you're doing.

>
I read your message as suggesting non-portable had to be a goal for 'A'<=c
&& c<='Z' to be the right thing. If you meant that non-portable can be
okay, just that you need to be aware of it, then agreed.

Exactly. Portability is good, all else being equal, but all else is
not always equal.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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"

[Hendrik Schober]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integralc onstant-expression&quot ; to &quot;integr al expression&quot ;

Keith Thompson wrote:

Hendrik Schober <spamtrap@gmx.d ewrites:

>Keith Thompson wrote:

>>"robertwessel 2@yahoo.com" <robertwessel2@ yahoo.comwrites :
>>>On Oct 28, 7:42 pm, JoelKatz <dav...@webmast er.comwrote:
>>>>What will be next? "case >=7:"?
>>>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.

Schobi

[Keith Thompson]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

Hendrik Schober <spamtrap@gmx.d ewrites:

Keith Thompson wrote:

>Hendrik Schober <spamtrap@gmx.d ewrites:

>>Keith Thompson wrote:

[...]

>>>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.

Since you snipped my argument, I have no idea why you disagree with
it.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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"

[Hendrik Schober]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integralc onstant-expression&quot ; to &quot;integr al expression&quot ;

Keith Thompson wrote:

Hendrik Schober <spamtrap@gmx.d ewrites:

>Keith Thompson wrote:

>>Hendrik Schober <spamtrap@gmx.d ewrites:
>>>Keith Thompson wrote:

[...]

>>>>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.

>
Since you snipped my argument, I have no idea why you disagree with
it.

Funny. My newsreader still shows it.

Schobi

[Keith Thompson]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

Hendrik Schober <spamtrap@gmx.d ewrites:

Keith Thompson wrote:

>Hendrik Schober <spamtrap@gmx.d ewrites:

>>Keith Thompson wrote:
>>>Hendrik Schober <spamtrap@gmx.d ewrites:
>>>>Keith Thompson wrote:

>[...]

>>>>>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.

>Since you snipped my argument, I have no idea why you disagree with
>it.

>
Funny. My newsreader still shows it.

I was referring to the text you replaced with "[...]".

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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"

[vippstar@gmail.com]

Re: C/C++ language proposal: Change the 'case expression' from&quot;integ ral constant-expression&quot ; to &quot;integr al expression&quot ;

On Oct 31, 10:56 am, Hendrik Schober <spamt...@gmx.d ewrote:

Keith Thompson wrote:

Hendrik Schober <spamt...@gmx.d ewrites:

Keith Thompson wrote:
>"robertwess... @yahoo.com" <robertwess...@ yahoo.comwrites :
>>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.

I'm going to restore mr Thompsons text: (it's where you have [...])

[It wouldn't.] The problem (as I think I've already said in this
thread) is that adding this syntax makes it much easier to check for
characters in the range 'A' to 'Z' *without* making it any easier to
check for characters that are uppercase letters.

It's not the least bit difficult to write bad code in C or C++ (this
is cross-posted), even with their current features, but let's not make
it even easier.

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.

My view on it: Syntactic sugar that would only complicate the
language(s) further without being a real convenience.

[Hendrik Schober]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integralc onstant-expression&quot ; to &quot;integr al expression&quot ;

vippstar@gmail. com wrote:

On Oct 31, 10:56 am, Hendrik Schober <spamt...@gmx.d ewrote:

>Keith Thompson wrote:

>>Hendrik Schober <spamt...@gmx.d ewrites:
>>>Keith Thompson wrote:
>>>>"robertwess ...@yahoo.com" <robertwess...@ yahoo.comwrites :
>>>>>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?

My view on it: Syntactic sugar that would only complicate the
language(s) further without being a real convenience.

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.

Schobi

[Keith Thompson]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

Hendrik Schober <spamtrap@gmx.d ewrites:

vippstar@gmail. com wrote:

>On Oct 31, 10:56 am, Hendrik Schober <spamt...@gmx.d ewrote:

>>Keith Thompson wrote:
>>>Hendrik Schober <spamt...@gmx.d ewrites:
>>>>Keith Thompson wrote:
>>>>>"robertwes s...@yahoo.com" <robertwess...@ yahoo.comwrites :
>>>>>>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((unsig ned 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_Keit h) kst-u@mib.org <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"

[Hendrik Schober]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integralc onstant-expression&quot ; to &quot;integr al expression&quot ;

Keith Thompson wrote:

Hendrik Schober <spamtrap@gmx.d ewrites:
[...]

> 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.

What would be a corresponding non-abuse?

Schobi

[James Kuyper]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integralc onstant-expression&quot ; to &quot;integr al expression&quot ;

Hendrik Schober wrote:

Keith Thompson wrote:

>Hendrik Schober <spamtrap@gmx.d ewrites:
>[...]

>> 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.

>
What would be a corresponding non-abuse?

if(isupper(c))