|
|
Flash Gordon wrote:
lawrence.jones@xxxxxxxxxxx wrote, On 29/03/08 01:17:
jacob navia <jacob@xxxxxxxxxx> wrote:
This is correct. But I think allowing case *ranges* would not affect
the generality of the optimization. lcc-win, for instance, generates
several secondary tables in the optimized search tree, when there are
different disjoint ranges of case values.
Yes, case ranges were seriously considered for C99 but ultimately were
rejected because they're less useful than they appear at first glance
and are an open invitation to lead novice programmers astray. For
example, an obvious range is 'A'...'Z', but that doesn't have the
generally expected behavior on many systems (e.g., IBM mainframes use
EBCDIC which has a number of interesting non-alphabetic characters
scattered amongst the letters).
I don't think that is a very good argument against it. The people who
would make that mistake are the people who currently do:
if (c>='A' && c<='Z')
so by forbidding ranges you are not, IMO, reducing errors just
preventing people from using a potentially useful feature.
If the feature would be so useful, why does every
example trot out 'A' ... 'Z', a useLESS construct? The
gcc documentation leads with that one and goes on to
exhibit 1 ... 5, but does not suggest a context in which
the construct would be appealing.
If someone's got an example where case ranges would
be significantly more useful and expressive, I'd be glad
to see it.
--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxxx
|
|