Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
switch and many case's. Any caveats?
134 views
Skip to first unread message
Test
May 8, 2012, 2:50:51 PM5/8/12
to
I am using a (some pseudo code):
switch (i)
{
case 1:
...
case 2:
...
...
case 249:
...
case 250:
...
}
where I have a couple hundred case's. Does this degrade performance and if so
what would a better way?
switch (i)
{
case 1:
...
case 2:
...
...
case 249:
...
case 250:
...
}
where I have a couple hundred case's. Does this degrade performance and if so
what would a better way?
Scott Fluhrer
May 8, 2012, 3:08:05 PM5/8/12
to
"Test" <test@.nil.invalid.com> wrote in message
news:qfqiq71bbsc6fpi30...@4ax.com...
evidence that it matters significantly in this specific case? Or, would you
be better off asking "is this the most maintainable way of implementing
this? Is it the most self-documenting? Is it the way that I am least
likely to get wrong (and cause bugs)?"
As for the question you asked, performance is, of course, a QoI issue which
depends on your specific compiler (and the specific optimization settings).
Most compilers I am familiar with handle this situation fairly well, though;
give a large range of cases with no large gaps, they usually create a jump
table, and index into that. If you have some specific knowledge that
suggests that performance is actually important in this case, you might try
coding something up with your compiler, and examining the generated code.
--
poncho
Kleuske
May 8, 2012, 3:08:40 PM5/8/12
to
On Tue, 08 May 2012 21:50:51 +0300, Test saw fit to publish the following:
It _may_ degrade performance, but that's only a headache if it's in some
critical section and not the main issue. Constructs like that _do_ degrade
readability and hence maintainability. Maybe lookup-tables and/or
pointers-to-function may improve your code, but it's impossible to tell
w/o more detail.
Using numbers as case-labels is almost always a bad idea. #define something
understandable instead.
critical section and not the main issue. Constructs like that _do_ degrade
readability and hence maintainability. Maybe lookup-tables and/or
pointers-to-function may improve your code, but it's impossible to tell
w/o more detail.
Using numbers as case-labels is almost always a bad idea. #define something
understandable instead.
jgharston
May 8, 2012, 3:17:09 PM5/8/12
to
Test wrote:
> where I have a couple hundred case's.
The plural of case is cases.
> where I have a couple hundred case's.
cat cats, dog dogs, table tables, tree trees, fire fires, case cases.
JGH
Eric Sosman
May 8, 2012, 3:17:49 PM5/8/12
to
least 257 case labels per switch, and the "C99" revision raised the
limit to 1023. So with "a couple hundred" cases you're safe, but with
"several hundred" you might get into trouble with C90 compilers. (A
particular C90 compiler may allow more than 257 cases, but the Standard
does not require all C90 compilers to do so.)
As for performance, you'll need to investigate on your own, most
likely by measurement. Realize that the results of the investigation
are not necessarily applicable to other machines, other compilers, or
even the same machine and compiler under different circumstances than
exactly what was measured. It is likely (but by no means certain) that
if the case numbers are "dense" and have few gaps, the performance for
large-N and moderate-N will be similar.
Finally, "a better way" depends quite a lot on the nature of what
you're doing. If your couple hundred cases are all doing similar
things, perhaps there's a way to parameterize the differences between
the cases and use an array of a couple hundred parameter values. Or
maybe you need an array of function pointers. Or maybe you need a
switch with a lot of cases -- it's hard to tell.
Consider also the matter of maintenance: If you expect to tinker
with the cases a lot, the notion of "better" should probably include
some thought for making the tinkering easier and error-resistant. You
do *not* want to edit a thousand-case switch to change the behavior of
case 426, recompile, test, and discover that you mistakenly changed
462 instead ...
--
Eric Sosman
eso...@ieee-dot-org.invalid
William Ahern
May 8, 2012, 3:27:07 PM5/8/12
to
For example, how sparse your case values are and the number of cases are two
possible parameters for the optimizing algorithm.
As for alternatives, it's hard to say. The easier it is for you to translate
your switch statement into an alternate control structure, the easier it'd
be for the compiler. If it's trivial to create a table of function pointers
with a simple index into the table, then it's likely your compiler could
generate something substantially equivalent.
You might want to research the algorithm and heuristics employed by your
preferred compiler. Alternatively, don't worry about it until you have
real-world data suggesting your switch statement is a bottleneck. For
example, if it's an op code dispatcher for a virtual machine and you have
numbers for a relevant workload suggesting your dispatcher could use more
attention.
Rui Maciel
May 8, 2012, 3:32:12 PM5/8/12
to
Kleuske wrote:
> Using numbers as case-labels is almost always a bad idea. #define
> something understandable instead.
Enums also work quite nicely, as the compiler is able to perform some sanity
> Using numbers as case-labels is almost always a bad idea. #define
> something understandable instead.
checks.
Rui Maciel
Andrew Smallshaw
May 8, 2012, 4:21:13 PM5/8/12
to
On 2012-05-08, Kleuske <kle...@nowhere.net> wrote:
> On Tue, 08 May 2012 21:50:51 +0300, Test saw fit to publish the following:
>
> On Tue, 08 May 2012 21:50:51 +0300, Test saw fit to publish the following:
>
>> where I have a couple hundred case's. Does this degrade performance and if so
>> what would a better way?
>
>> what would a better way?
>
> Using numbers as case-labels is almost always a bad idea. #define something
> understandable instead.
In a complex case such as this I tend to find them more manageable:
> understandable instead.
I can't comment as to the OP's code but in my experience large
switches are usually the result of implementing a complex FSM. If
you have 250 states each one probably represents some form of
intersection between a dozen or more variables and creating meaningful
names for them all that a remotely suitable for use as manifest
constant or enumerated values is a complete non-starter.
What would you call the state "output buffer is full, input buffer
has been partially processed, a timeout occurred in the last
iteration of processing, a peer system has posted some changes to
the data that need to be accounted for, and the string holding the
furry dice has snapped"?
The notes designing this code are simply going to refer to it as
"state 247". If code can't be self-documenting then at least you
want a one-to-one correspondence beween your design notes and the
code. You can always summarise the essential conditions for a
particular case in comments if you want. You can also make a case
that the FSM needs simplification but that is a wider structural
issue that may or may not be appropriate in a given context.
Returning to the OP's question my opinion tends to be "don't worry
about it" for things like this. With modern optimising compilers
you really have no idea what code is going to be generated and
attempting to second-guess them is waste of time. If it's idenfied
as a problem you can always break it up in some manner, e.g:
switch (i >> 4) {
case 0:
switch (i & 15) {
...
}
...
}
However, my default position would be not to bother until and unless
that code is actually identified as problematic, especially if the
different cases are largely or entirely sequential in nature.
--
Andrew Smallshaw
and...@sdf.lonestar.org
Paul N
May 8, 2012, 5:41:48 PM5/8/12
to
the compiler clearly what you want, and it can choose the best way of
implementing it itself.
If you can be confident that i is in the range 1-250, and can't find a
way of telling the compiler this, then an array as suggested by
William Ahern might be slightly quicker. Though it might not be worth
the hit to readability and maintainability.
Malcolm McLean
May 8, 2012, 7:28:23 PM5/8/12
to
בתאריך יום שלישי, 8 במאי 2012 19:50:51 UTC+1, מאת Test:
It's to be hoped that the compiler produces a jump table for such a long switch. But you can't control that. Switches in inner loops often degrade performance, for instance the switch on the instruction opcode really hammers a C Java Virtual Machine.
There's no one answer. If there was, there wouldn't be a problem, because the compiler would implement it.
Are the labels contiguous? That nake it easier for the compiler to build the jump table.
Are all cases equally likely, or do you have a titles type distribution - thousands of Mr's, about a third Miss, Mrs and Ms, a sprinkling of Drs and Revs, and then a few very rare Profs, Lords, Sirs, His Divine Grace's and so on. In that case, you can possibly speed things up by a if() to filter out the common cases.
Then you can often implement a structured search. Instead of an if else ladder, you have a binary search. Of course there's no point in simply doing a binary search on the case labels, because if that was the fastest way to switch the compler would already do it. You need to apply knowledge about the distribution of labels to make the likely branches more likely to be taken (the processor probably assumes that an if will be taken, and so piplines it, so you arrnage the common cases to be true. But you really need to look at the assembly.)
But there's no easy answer. None of this will necessarily work. Inherently switching is a rather slow operation.
--
Basic Algorithms. A massive C programming resource.
http://www.malcolmmclean.site11.com/www
> I am using a (some pseudo code):
> switch (i)
> switch (i)
> where I have a couple hundred case's. Does this degrade performance and if so
> what would a better way?
>
It could well.
> what would a better way?
>
It's to be hoped that the compiler produces a jump table for such a long switch. But you can't control that. Switches in inner loops often degrade performance, for instance the switch on the instruction opcode really hammers a C Java Virtual Machine.
There's no one answer. If there was, there wouldn't be a problem, because the compiler would implement it.
Are the labels contiguous? That nake it easier for the compiler to build the jump table.
Are all cases equally likely, or do you have a titles type distribution - thousands of Mr's, about a third Miss, Mrs and Ms, a sprinkling of Drs and Revs, and then a few very rare Profs, Lords, Sirs, His Divine Grace's and so on. In that case, you can possibly speed things up by a if() to filter out the common cases.
Then you can often implement a structured search. Instead of an if else ladder, you have a binary search. Of course there's no point in simply doing a binary search on the case labels, because if that was the fastest way to switch the compler would already do it. You need to apply knowledge about the distribution of labels to make the likely branches more likely to be taken (the processor probably assumes that an if will be taken, and so piplines it, so you arrnage the common cases to be true. But you really need to look at the assembly.)
But there's no easy answer. None of this will necessarily work. Inherently switching is a rather slow operation.
--
Basic Algorithms. A massive C programming resource.
http://www.malcolmmclean.site11.com/www
Jianjun Mao
May 8, 2012, 10:38:14 PM5/8/12
to
1. Using function array to implement this. Every state maps to a function, then store this function into an array named func_arr[N]. And you can call the function like this: func_arr[state](...).
2. In my point of view, hundreds of cases will not degrade the performance because of the high speed CPU, and many application are implemented in this way, such as: lex and yacc.
2. In my point of view, hundreds of cases will not degrade the performance because of the high speed CPU, and many application are implemented in this way, such as: lex and yacc.
nick_keigh...@hotmail.com
May 9, 2012, 3:10:49 AM5/9/12
to
On Tuesday, May 8, 2012 9:21:13 PM UTC+1, Andrew Smallshaw wrote:
> On 2012-05-08, Kleuske <kle...@nowhere.net> wrote:
> > On Tue, 08 May 2012 21:50:51 +0300, Test saw fit to publish the following:
> >> where I have a couple hundred case's. Does this degrade performance and if > >> so what would a better way?
> >
> > Using numbers as case-labels is almost always a bad idea. #define something
> > understandable instead.
>
> In a complex case such as this I tend to find them more manageable:
> I can't comment as to the OP's code but in my experience large
> switches are usually the result of implementing a complex FSM. If
> you have 250 states each one probably represents some form of
> intersection between a dozen or more variables and creating meaningful
> names for them all that a remotely suitable for use as manifest
> constant or enumerated values is a complete non-starter.
I'd argue it might be time to consider partitioning your SM when it's got 250 states. I've seen large SMs that made sense but if I recall correctly it was the events that exploded (one event for every character maybe?). It was interfacing to Telex so that was a *long* time ago!
> On 2012-05-08, Kleuske <kle...@nowhere.net> wrote:
> > On Tue, 08 May 2012 21:50:51 +0300, Test saw fit to publish the following:
> >> where I have a couple hundred case's. Does this degrade performance and if > >> so what would a better way?
> >
> > Using numbers as case-labels is almost always a bad idea. #define something
> > understandable instead.
>
> In a complex case such as this I tend to find them more manageable:
> I can't comment as to the OP's code but in my experience large
> switches are usually the result of implementing a complex FSM. If
> you have 250 states each one probably represents some form of
> intersection between a dozen or more variables and creating meaningful
> names for them all that a remotely suitable for use as manifest
> constant or enumerated values is a complete non-starter.
> What would you call the state "output buffer is full, input buffer
> has been partially processed, a timeout occurred in the last
> iteration of processing, a peer system has posted some changes to
> the data that need to be accounted for, and the string holding the
> furry dice has snapped"?
> The notes designing this code are simply going to refer to it as
> "state 247". If code can't be self-documenting then at least you
> want a one-to-one correspondence beween your design notes and the
> code. You can always summarise the essential conditions for a
> particular case in comments if you want. You can also make a case
> that the FSM needs simplification but that is a wider structural
> issue that may or may not be appropriate in a given context.
boB
May 9, 2012, 4:17:01 PM5/9/12
to
On Tue, 8 May 2012 19:38:14 -0700 (PDT), Jianjun Mao
<justm...@gmail.com> wrote:
>1. Using function array to implement this. Every state maps to a function, then store this function into an array named func_arr[N]. And you can call the function like this: func_arr[state](...).
This is what I do and it works well.
<justm...@gmail.com> wrote:
>1. Using function array to implement this. Every state maps to a function, then store this function into an array named func_arr[N]. And you can call the function like this: func_arr[state](...).
>
>2. In my point of view, hundreds of cases will not degrade the performance because of the high speed CPU, and many application are implemented in this way, such as: lex and yacc.
times, switch/case is fine.
10 years ago I had a state machine that had about 30 cases and I
found that the end code ended up comparing, one by one until it found
the case. This was an embedded time sensitive project and so I then
went to a function pointer system which of course went
to the function right away.
This is a very good reason for C programmers to at least be able to
read the assembly language output of the compiler, in addition to be
able to debug the code properly.
boB
Joe keane
May 9, 2012, 4:26:06 PM5/9/12
to
In article <qfqiq71bbsc6fpi30...@4ax.com>,
write the code.
It would help if you could explain a bit why there are two hundred
cases. I have seen code where there are a couple dozen cases, and i
thought trying to 'modularize' it would result in code that is less
readable and probably slower.
Test <test@.nil.invalid.com> wrote:
>switch (i)
> {
> case 1:
> ...
> case 2:
> ...
> ...
> case 249:
> ...
> case 250:
> ...
> }
If this is really what you want to do, i think that's the best way to
>switch (i)
> {
> case 1:
> ...
> case 2:
> ...
> ...
> case 249:
> ...
> case 250:
> ...
> }
write the code.
It would help if you could explain a bit why there are two hundred
cases. I have seen code where there are a couple dozen cases, and i
thought trying to 'modularize' it would result in code that is less
readable and probably slower.
Quentin Pope
May 9, 2012, 5:09:59 PM5/9/12
to
On Tue, 08 May 2012 15:17:49 -0400, Eric Sosman wrote:
> On 5/8/2012 2:50 PM, Test wrote:
>> I am using a (some pseudo code):
>> switch (i)
>> {
>> case 1:
>> ...
>> case 2:
>> ...
>> ...
>> case 249:
>> ...
>> case 250:
>> ...
>> }
>>
>> where I have a couple hundred case's. Does this degrade performance and
>> if so what would a better way?
>
> The original ANSI "C90" Standard required compilers to support at
> least 257 case labels per switch, and the "C99" revision raised the
> limit to 1023. So with "a couple hundred" cases you're safe, but with
> "several hundred" you might get into trouble with C90 compilers. (A
> particular C90 compiler may allow more than 257 cases, but the Standard
> does not require all C90 compilers to do so.)
I believe the requirement is that it must accept *at least one*
> On 5/8/2012 2:50 PM, Test wrote:
>> I am using a (some pseudo code):
>> switch (i)
>> {
>> case 1:
>> ...
>> case 2:
>> ...
>> ...
>> case 249:
>> ...
>> case 250:
>> ...
>> }
>>
>> where I have a couple hundred case's. Does this degrade performance and
>> if so what would a better way?
>
> The original ANSI "C90" Standard required compilers to support at
> least 257 case labels per switch, and the "C99" revision raised the
> limit to 1023. So with "a couple hundred" cases you're safe, but with
> "several hundred" you might get into trouble with C90 compilers. (A
> particular C90 compiler may allow more than 257 cases, but the Standard
> does not require all C90 compilers to do so.)
conforming program with this number of case labels, so there is no
guarantee you're safe for any particular program.
88888 Dihedral
May 9, 2012, 5:30:41 PM5/9/12
to
Test於 2012年5月9日星期三UTC+8上午2時50分51秒寫道：
In the above software, this kind of approach becomes a linear search
for an action according to i's value in the run time for the total number
of cases.
Of course, if it is not time critical, one can just leave the code alone.
for an action according to i's value in the run time for the total number
of cases.
Of course, if it is not time critical, one can just leave the code alone.
boB
May 9, 2012, 7:50:01 PM5/9/12
to
On 9 May 2012 15:17:01 -0500, boB <K7IQ> wrote:
>On Tue, 8 May 2012 19:38:14 -0700 (PDT), Jianjun Mao
><justm...@gmail.com> wrote:
>
>>1. Using function array to implement this. Every state maps to a function, then store this function into an array named func_arr[N]. And you can call the function like this: func_arr[state](...).
>
>
>This is what I do and it works well.
>
>
>>
>>2. In my point of view, hundreds of cases will not degrade the performance because of the high speed CPU, and many application are implemented in this way, such as: lex and yacc.
>
>
>Depends on the CPU and how important speed is of course.
Oooops !!! I should have said, depends on the compiler !!
>On Tue, 8 May 2012 19:38:14 -0700 (PDT), Jianjun Mao
><justm...@gmail.com> wrote:
>
>>1. Using function array to implement this. Every state maps to a function, then store this function into an array named func_arr[N]. And you can call the function like this: func_arr[state](...).
>
>
>This is what I do and it works well.
>
>
>>
>>2. In my point of view, hundreds of cases will not degrade the performance because of the high speed CPU, and many application are implemented in this way, such as: lex and yacc.
>
>
>Depends on the CPU and how important speed is of course.
boB
Tim Rentsch
May 10, 2012, 12:52:26 PM5/10/12
to
"case" as an English word and 'case' as a C keyword. So
for example
switch(n%10){
case 0:
case 1: x = 0; break;
case 2:
case 3:
case 5:
case 7: x = 1; break;
case 4:
case 6:
case 8:
case 9: x = 3; break;
}
There are three cases, but 10 case's.
Tim Rentsch
May 10, 2012, 1:12:11 PM5/10/12
to
to accept any strictly conforming program. A program that is
strictly conforming in all other regards, and also uses no more
than 1023 case labels in any switch() statement, is strictly
conforming and so must be accepted by any conforming implementation.
Quentin Pope
May 10, 2012, 4:28:08 PM5/10/12
to
"The implementation shall be able to translate and execute at least one
program that contains at least one instance of every one of the following
limits: ..."
This is quite a weak guarantee.
James Kuyper
May 10, 2012, 5:52:32 PM5/10/12
to
conforming hosted implementation shall accept any strictly conforming
program." Depending upon how "accept" is defined, that could be a very
strong guarantee, making up for the weakness of 5.2.4.1 - but the
standard fails to define "accept".
Some people have argued that "accept" must be equivalent to "translate
and execute". However, if that were the case, there would be no such
thing as a conforming implementation, because it's a relatively
straightforward task to describe a strictly conforming program that will
exceed the capacity of any particular implementation to handle it.
5.2.4.1 doesn't place any limits, explicit or implicit, on the total
size of a program, whether measured in terms of characters of source
code or in terms of tokens after phase 4 is complete. There's not many
implementations out there, if any, which could accept, in that sense, a
strictly conforming but arbitrarily long program with non-trivial
semantics that met every upper limit listed in 5.2.4.1 - not just once,
like the "one program", but at every possible opportunity.
Creating such a program would be more of a problem than describing it.
Any program which is too complex for a C implementation to parse, is
probably going to be very difficult to generate, too.
The ordinary English usage of "accept" allows me to say that I've
accepted a gift as long as I took it from the hands of the giver and
thanked that person for the gift, even if I never opened the gift, and
threw it away as soon as the giver was out of sight. Similarly, consider
a system which:
1. Always issues a diagnostic message saying "Your program may contain
defects" to satisfy 5.1.1.3p1.
2. Parses the program though phases 1-4 to determine whether any #error
directive survived conditional processing. If so, it issues the
specified error message, satisfying 6.10p5, and does nothing else with
it, satisfying 4p4. Otherwise, it issues a message saying "program
accepted", satisfying 4p6.
3. Checks to see whether the program is an exact match for the "one
program" mentioned in 5.2.4.1, and if so, translates and executes it
correctly. Otherwise, it does nothing more with it.
I contend that such a system could conform to all of the actual
requirements of the C99 standard (rather than the intended requirements,
which I gather were a bit stronger). C2011 seems to contain all of the
same weasel wording that allowed this to be a conforming C99
implementation, but I haven't had time to study it in detail to be sure
about that.
Nobody
May 10, 2012, 7:07:54 PM5/10/12
to
On Thu, 10 May 2012 20:28:08 +0000, Quentin Pope wrote:
> 5.2.4.1
> "The implementation shall be able to translate and execute at least one
> program that contains at least one instance of every one of the following
> limits: ..."
>
> This is quite a weak guarantee.
AIUI, the intent is to avoid requiring an implementation to handle the
> 5.2.4.1
> "The implementation shall be able to translate and execute at least one
> program that contains at least one instance of every one of the following
> limits: ..."
>
> This is quite a weak guarantee.
worst-case combinations of limits, e.g. a structure having 1023 members, each of
which is a structure having 1023 members, and so on, nested to 63 levels
(i.e. 1023^63 members in total), or a function with 127 parameters, each
of which has such a pathological structure as its type.
IOW, if the implementation has fixed limits, they can't be any lower than
the values specified, but it doesn't have to support every possible
combination of those limits.
nick_keigh...@hotmail.com
May 11, 2012, 3:05:40 AM5/11/12
to
Tim Rentsch
May 11, 2012, 12:25:30 PM5/11/12
to
making, namely, that your claim about what the requirements are
for what implementations must accept is wrong.
> This is quite a weak guarantee.
is not a guarantee. This sentence, along with almost every other
sentence in the Standard, is simply part of the definition of what
constitutes a conforming implementation of ISO C. Definitions
don't make promises; they are just definitions.
88888 Dihedral
May 11, 2012, 4:20:07 PM5/11/12
to
Tim Rentsch於 2012年5月11日星期五UTC+8上午12時52分26秒寫道：
I suggest you can use the following method to speed up!
s=1<<n; //
if (s&(1|2)) { ..... // case 0 or 1 }
else if (s&(4|8|32|128)) { ....// case 2,3,5,7 }
else if (s&(16|64|256|512)){ ... // };
s=1<<n; //
if (s&(1|2)) { ..... // case 0 or 1 }
else if (s&(4|8|32|128)) { ....// case 2,3,5,7 }
else if (s&(16|64|256|512)){ ... // };
Richard Damon
May 12, 2012, 7:46:21 PM5/12/12
to
translate and execute one of them. The compiler is allowed to fail to
translate any program (except that one special one for conformance) due
to exceeding translator resource limits, and those limits are NOT
restricted to the enumerated list, nor is not exceeding any of them an
assurance that a translation limit will not be hit.
One problem with the standard, is that it is leaves a lot of wiggle
room, and it is possible for a pathological compiler to pass the
conformance test due to the way the translation limit rules are written
(unless they have cleaned it up in the latest version).
Tim Rentsch
May 13, 2012, 1:09:07 PM5/13/12
to
or even have defined behavior. So the bar for what an implementation
must be able to do in terms of which programs it necessarily will
translate is quite low.
> The compiler is allowed to fail to
> translate any program (except that one special one for conformance) due
> to exceeding translator resource limits, and those limits are NOT
> restricted to the enumerated list, nor is not exceeding any of them an
> assurance that a translation limit will not be hit.
is outside what the Standard concerns itself with, and explicitly so.
> One problem with the standard, is that it is leaves a lot of wiggle
> room, and it is possible for a pathological compiler to pass the
> conformance test due to the way the translation limit rules are written
> (unless they have cleaned it up in the latest version).
what it is the Standard sets out to do. The point of standardizing
"the C language" is to define what constitutes an implmentation of C.
Not what constitutes a _good_ implementation, but just what constitues
an implementation. The stipulation in 5.2.4.1 p1 serves that purpose
fairly well, I would say.
Furthermore, there is another important property, often overlooked,
that conforming implementations must satisfy. That property is
conditional correctness: if an implementation does accept a program
and translate it successfully, then when the program is executed (and
assuming the execution environment has sufficient resources to run the
program to completion), then the executable _must do the right thing_
(modulo hardware failures and OS bugs, which are outside the scope of
the Standard) as defined by the semantic descriptions in the Standard.
In other words, for any program that an implementation does translate,
the translation process must have no bugs. Moreover that includes not
just strictly conforming programs but _any_ program that has defined
behavior, including unspecified behavior or implementation-defined
behavior. In practical terms this more stringent requirement is both
more important and sufficient to provide a good level of quality in
all conforming implementations.
Francois Grieu
May 14, 2012, 8:01:44 AM5/14/12
to
Francois Grieu
James Kuyper
May 14, 2012, 8:24:09 AM5/14/12
to
to check whether a switch statement based upon a value of enumerated
type has case labels that cover all of the associated enumeration
constants. If the appropriate option (-Wswitch or -Wswitch-enum) is
turned on, it will issue a warning if they do not. It will also warn if
a value outside the range of the enumerators is used for a case label.
No feature of C++ is needed to implement such warnings.
Possibly you're thinking of -Wenum-compare, which is C++ specific, but
has nothing to do with case labels.
--
James Kuyper
Tim Rentsch
May 14, 2012, 2:51:14 PM5/14/12
to
by a C implementation, if the implementors chose to provide an
option for that; issuing diagnostics, for any reason, is always
conforming.
A. K.
May 17, 2012, 11:13:12 AM5/17/12
to
On 08.05.2012 20:50, Test wrote:
> I am using a (some pseudo code):
> switch (i)
> {
> case 1:
> ...
> case 2:
> ...
> ...
> case 249:
> ...
> case 250:
> ...
> }
>
> where I have a couple hundred case's. Does this degrade performance and if so
> what would a better way?
Giant switching is fairly common in virtual machines. The Forth guys
> I am using a (some pseudo code):
> switch (i)
> {
> case 1:
> ...
> case 2:
> ...
> ...
> case 249:
> ...
> case 250:
> ...
> }
>
> where I have a couple hundred case's. Does this degrade performance and if so
> what would a better way?
have spent a lot of investigation on it. Result: it depends too much on
the processor, branch prediction behaviour, caching, execution pipeline
stallment etc. So there is no generic answer to performance optimization.
If you want to be portable: take the switch
If you use gcc or vc: take computed goto's
And it your problem is really a VM: keep the virtual instruction pointer
aligned ie. don't use bytes but 32-bit integers. This can really boost
speed.
Tim Rentsch
May 17, 2012, 4:02:12 PM5/17/12
to
the items referred to are textual entities of some sort. This
sentence, for example, has two This's, two and's, two eight's, two
example's, two for's, two has's, two sentence's, and eight two's.
We can count by twos, but the last sentence has eight two's, not
eight twos. Young children go through the terrible twos; it is
only later (we hope!) that they are taught two's complement. Or we
might say the decimal representation of 100 factorial has seven 7's
in it. From this point of view there is no exception in the two
cases illustrated above (and, please forgive me, pun intended).
Note that I'm not claiming this is right, only that it's my belief
that it's right (and it's been a rather long time since I last
opened my Chicago Manual of Style). Still, it does seem fair to
claim that the usage is -- at least! -- defensible.
Ben Bacarisse
May 17, 2012, 6:15:37 PM5/17/12
to
it should be avoided except where it's really needed to make the plural
obvious. The only case it endorses unequivocally is that of single
letters ("Mind your p's and q's"). It includes no special case of a
textual reference being made plural.
The "Oxford Dictionary of American Usage and Style" does not include
this use of the apostrophe. The only use of an apostrophe for plurals
is its use "to mark the plural of an acronym, number, or letter".
Fowler does not mention it.
And many reasonable writers (or editors) did not use this apostrophe.
For example, Shakespeare's "Tellest thou me of ifs", Centlivre's "But me
no Buts", and Kipling's "One million Hows, two million Wheres, And seven
million Whys". You might not consider these as references to "textual
entities of some sort". Maybe there are too metaphorical, despite being
reference to words.
> Note that I'm not claiming this is right, only that it's my belief
> that it's right (and it's been a rather long time since I last
> opened my Chicago Manual of Style). Still, it does seem fair to
> claim that the usage is -- at least! -- defensible.
argued in this sort of case. That way, everyone can be right.
--
Ben.
Tim Rentsch
May 18, 2012, 2:06:45 PM5/18/12
to
the favor.
> Gower's "The Complete Plain Words" says
> it should be avoided except where it's really needed to make the plural
> obvious. The only case it endorses unequivocally is that of single
> letters ("Mind your p's and q's"). It includes no special case of a
> textual reference being made plural.
otherwise? To me the important aspect is distinguishing the concept
from the text or word used to represent it, as might be done with
quotes, eg, "the variable x is a double" versus "x was declared
using 'double'".
> The "Oxford Dictionary of American Usage and Style" does not include
> this use of the apostrophe. The only use of an apostrophe for plurals
> is its use "to mark the plural of an acronym, number, or letter".
to convey here - a word-as-word, or keyword, is treated as if it
were a single ideogram.
> Fowler does not mention it.
However, I didn't learn much from this statement, without
knowing what else Fowler might have to say about usage
when writing about words as text. I suppose I should
spend some time reading Fowler now for my own further
education if nothing else.
> And many reasonable writers (or editors) did not use this apostrophe.
> For example, Shakespeare's "Tellest thou me of ifs", Centlivre's "But me
> no Buts", and Kipling's "One million Hows, two million Wheres, And seven
> million Whys". You might not consider these as references to "textual
> entities of some sort". Maybe there are too metaphorical, despite being
> reference to words.
than to the particular words. Also the context is important -
we wouldn't expect the same kind of attention to such distinctions
in poetry or regular prose as we would in technical writing. In
technical writing the distinctions are often important; in poetry
the shape and sound of the words is typically more important than
removing confusion or ambiguity.
>> Note that I'm not claiming this is right, only that it's my belief
>> that it's right (and it's been a rather long time since I last
>> opened my Chicago Manual of Style). Still, it does seem fair to
>> claim that the usage is -- at least! -- defensible.
>
> I am sure there is support for this usage, but I like to see both sides
> argued in this sort of case. That way, everyone can be right.
is not officially sanctioned, at least not directly. What
I was meaning to claim is that this rule is often observed
in writing by technical people, and not just with respect
to keywords or programming terms.
Ben Bacarisse
May 18, 2012, 10:37:24 PM5/18/12
to
Tim Rentsch <t...@alumni.caltech.edu> writes:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>
>> Tim Rentsch <t...@alumni.caltech.edu> writes:
<snip>
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>
>> Tim Rentsch <t...@alumni.caltech.edu> writes:
>>> Actually I believe it is standard usage in ordinary English when
>>> the items referred to are textual entities of some sort. This
>>> sentence, for example, has two This's, two and's, two eight's, two
>>> example's, two for's, two has's, two sentence's, and eight two's.
<snip>
>>> the items referred to are textual entities of some sort. This
>>> sentence, for example, has two This's, two and's, two eight's, two
>>> example's, two for's, two has's, two sentence's, and eight two's.
>> Gower's "The Complete Plain Words" says
>> it should be avoided except where it's really needed to make the plural
>> obvious. The only case it endorses unequivocally is that of single
>> letters ("Mind your p's and q's"). It includes no special case of a
>> textual reference being made plural.
>
> What does it say (or does it say anything) about textual references
> otherwise?
Nothing, as far as I can tell, but it's not a simple concept to look up.
>> it should be avoided except where it's really needed to make the plural
>> obvious. The only case it endorses unequivocally is that of single
>> letters ("Mind your p's and q's"). It includes no special case of a
>> textual reference being made plural.
>
> What does it say (or does it say anything) about textual references
> otherwise?
<snip>
>> The "Oxford Dictionary of American Usage and Style" does not include
>> this use of the apostrophe. The only use of an apostrophe for plurals
>> is its use "to mark the plural of an acronym, number, or letter".
>
> All of these more or less correspond to the principle I am trying
> to convey here - a word-as-word, or keyword, is treated as if it
> were a single ideogram.
Right. But I cut the quote off. It goes on to say that it's now more
>> this use of the apostrophe. The only use of an apostrophe for plurals
>> is its use "to mark the plural of an acronym, number, or letter".
>
> All of these more or less correspond to the principle I am trying
> to convey here - a word-as-word, or keyword, is treated as if it
> were a single ideogram.
usual to drop the apostrophe (except for letters).
>> Fowler does not mention it.
>
> You definitely outclass me in knowledge of matters style.
>
> However, I didn't learn much from this statement, without
> knowing what else Fowler might have to say about usage
> when writing about words as text. I suppose I should
> spend some time reading Fowler now for my own further
> education if nothing else.
for some plurals *is* mentioned, but in a section on possessives:
mps, the 1990s, etc. The apostrophe is no longer normally used in the
plural of abbreviated forms (e.g. Several MPs were standing around),
although it is of course used in the possessive (e.g. The BBC’s
decision to go ahead with the broadcast). It is used in plurals when
clarity calls for it, e.g. Dot your i's and cross your t's.
That's all. Much the same as the other advice, and nothing specifically
about textual references.
<snip>
--
Ben.
Tim Rentsch
May 21, 2012, 12:23:29 PM5/21/12
to
>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
[snip]
>>> Fowler does not mention it.
>>
>> You definitely outclass me in knowledge of matters style.
>>
>> However, I didn't learn much from this statement, without
>> knowing what else Fowler might have to say about usage
>> when writing about words as text. I suppose I should
>> spend some time reading Fowler now for my own further
>> education if nothing else.
>
> Turns out I was wrong, so no "outclassing" is possible. The apostrophe
> for some plurals *is* mentioned, but in a section on possessives:
>
> mps, the 1990s, etc. The apostrophe is no longer normally used in the
> plural of abbreviated forms (e.g. Several MPs were standing around),
> although it is of course used in the possessive (e.g. The BBC's
> decision to go ahead with the broadcast). It is used in plurals when
> clarity calls for it, e.g. Dot your i's and cross your t's.
>
> That's all. Much the same as the other advice, and nothing specifically
> about textual references.
For me that last quoted sentence is key, because the motivation
for using an apostrophe in the first place was clarity, ie, to
distinguish between a word used in its normal English sense and
the same "word" but used with a different, technical meaning.
[snip]
>>
>>> The "Oxford Dictionary of American Usage and Style" does not include
>>> this use of the apostrophe. The only use of an apostrophe for plurals
>>> is its use "to mark the plural of an acronym, number, or letter".
>>
>> All of these more or less correspond to the principle I am trying
>> to convey here - a word-as-word, or keyword, is treated as if it
>> were a single ideogram.
>
> Right. But I cut the quote off. It goes on to say that it's now more
> usual to drop the apostrophe (except for letters).
That is good to know. Thank you.
>>> The "Oxford Dictionary of American Usage and Style" does not include
>>> this use of the apostrophe. The only use of an apostrophe for plurals
>>> is its use "to mark the plural of an acronym, number, or letter".
>>
>> All of these more or less correspond to the principle I am trying
>> to convey here - a word-as-word, or keyword, is treated as if it
>> were a single ideogram.
>
> Right. But I cut the quote off. It goes on to say that it's now more
> usual to drop the apostrophe (except for letters).
>>> Fowler does not mention it.
>>
>> You definitely outclass me in knowledge of matters style.
>>
>> However, I didn't learn much from this statement, without
>> knowing what else Fowler might have to say about usage
>> when writing about words as text. I suppose I should
>> spend some time reading Fowler now for my own further
>> education if nothing else.
>
> Turns out I was wrong, so no "outclassing" is possible. The apostrophe
> for some plurals *is* mentioned, but in a section on possessives:
>
> mps, the 1990s, etc. The apostrophe is no longer normally used in the
> plural of abbreviated forms (e.g. Several MPs were standing around),
> although it is of course used in the possessive (e.g. The BBC's
> decision to go ahead with the broadcast). It is used in plurals when
> clarity calls for it, e.g. Dot your i's and cross your t's.
>
> That's all. Much the same as the other advice, and nothing specifically
> about textual references.
for using an apostrophe in the first place was clarity, ie, to
distinguish between a word used in its normal English sense and
the same "word" but used with a different, technical meaning.
Old Wolf
May 23, 2012, 4:09:39 PM5/23/12
to
On May 9, 6:50 am, Test <test@.nil.invalid.com> wrote:
> where I have a couple hundred case's. Does this degrade performance and if so
> what would a better way?
It's a heck of a lot better than:
> where I have a couple hundred case's. Does this degrade performance and if so
> what would a better way?
GOTO 400*(I=0)+440*(I=1)+490*(I=2)+600*(I=3)+630*(I=4)+
....
+6675*(I=213)
0 new messages