445,812 Members | 1,288 Online
Need help? Post your question and get tips & solutions from a community of 445,812 IT Pros & Developers. It's quick & easy.

# Does Casting Slow a Program Down?

 P: n/a If I had code like this. unsigned short usLimit=10 int a[10], i; for (i=0; i<(int)usLimit; ++i) { a[i]=(int)usLimit; } would it run slower than this? int a[10], i, iLimit=10; for (i=0; i
23 Replies

 P: n/a On 31 Jan 2007 06:50:47 -0800, "PeterOut" wrote: >If I had code like this.unsigned short usLimit=10 <<<<< Missing semicolon >int a[10], i;for (i=0; i<(int)usLimit; ++i){ a[i]=(int)usLimit;}would it run slower than this?int a[10], i, iLimit=10;for (i=0; i

 P: n/a PeterOut said: If I had code like this. unsigned short usLimit=10 int a[10], i; for (i=0; i<(int)usLimit; ++i) { a[i]=(int)usLimit; } would it run slower than this? int a[10], i, iLimit=10; for (i=0; i

 P: n/a PeterOut wrote: If I had code like this. unsigned short usLimit=10 int a[10], i; for (i=0; i<(int)usLimit; ++i) { a[i]=(int)usLimit; } would it run slower than this? int a[10], i, iLimit=10; for (i=0; i

 P: n/a PeterOut wrote: If I had code like this. unsigned short usLimit=10 int a[10], i; for (i=0; i<(int)usLimit; ++i) { a[i]=(int)usLimit; } would it run slower than this? int a[10], i, iLimit=10; for (i=0; i

 P: n/a On Jan 31, 10:01 am, Zara If the compiler detectes tha usLimit and iLimit are constants, then it may detect that (int)usLimit is also constant and it would probably generate the exact same machine code for both samples. But this behaviour depends on the optimizations capabilities an settings of the compiler, and of the code surrounding the snippet you have shown us. You may help the compiler declaring either const unsigned short usLimit=10; or const int iLimit=10; Thanks very much for your fast reply. I was thinking in general terms. usLimit/iLimit are given a constant value in the example that I posted but I was thinking in terms of their being variables that are determined by input data and/or passed as arguments to a function. Also, what about casting a (single precision) float to a double or vice versa? Would that impact the run time or would it depend on the compiler? Thanks again, Peter. Jan 31 '07 #6

 P: n/a PeterOut wrote: Thanks very much for your fast reply. I was thinking in general terms. usLimit/iLimit are given a constant value in the example that I posted but I was thinking in terms of their being variables that are determined by input data and/or passed as arguments to a function. Also, what about casting a (single precision) float to a double or vice versa? Would that impact the run time or would it depend on the compiler? Thanks again, Peter. If you're using gcc, use the -s option and check the assembler output of both versions. If you're using another compiler - lookup how to produce the intermediate assembler output (if it has that functionality). Jan 31 '07 #7

 P: n/a PeterOut wrote: On Jan 31, 10:01 am, Zara

 P: n/a "santosh"

 P: n/a "Serve Laurijssen"

 P: n/a "PeterOut"

 P: n/a On Wed, 31 Jan 2007 15:04:29 +0000, Chris Dollin wrote: >PeterOut wrote: >If I had code like this.unsigned short usLimit=10int a[10], i;for (i=0; i<(int)usLimit; ++i){ a[i]=(int)usLimit;}would it run slower than this?int a[10], i, iLimit=10;for (i=0; i

 P: n/a On Feb 1, 2:04 am, Chris Dollin

 P: n/a In article <11********************@a34g2000cwb.googlegroups.c om>, Peter Nilsson You'll find there's no shortage of implementations whereunsigned short promotes to unsigned int, not int. ANSI X.3-1989 3.2.1.1 Characters and Integers A char, a short int, or an int bit-field, or their signed or unsigned varieties, or an enumeration type, may be used in any expression whereaever an int or unsigned int may be used. If an int can represent all values of the original type, type value is converted to an int; otherwise it is converted to an unsigned int. These are called the integral promotions. All other arithmetic types are unchanged by the integral promotions. The integral promotions preserve value including sign. As discussed earlier, whether a "plain" char is treated as signed is implementation-defined. Hence, implementations can only promote unsigned short to unsigned int if the signed int cannot hold all the values of the unsigned short -- which is to say, implementations on which unsigned short and unsigned int are the same size. On implementations on which int has more value bits than unsigned short does, the promotion must be to signed int, not to unsigned int. The only implementations I can think of in which unsigned int and unsigned short are the same size, are ones that have 16 bit int -- that or they are DSPs that use the same large size for short and int and long. Are those the implementations you were thinking of in your "no shortage" statement? -- I was very young in those days, but I was also rather dim. -- Christopher Priest Jan 31 '07 #14

 P: n/a Peter Nilsson wrote: On Feb 1, 2:04 am, Chris Dollin >It might, but it would have nothing to do with the casts,since they're both unnecessary -- `usLimit` isconverted from `unsigned short` to `int` regardless. No. You'll find there's no shortage of implementations where unsigned short promotes to unsigned int, not int. If they do they are not standards compliant. I agree that they should, but that is neither here nor there. -- "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews Feb 1 '07 #15

 P: n/a CBFalconer It might, but it would have nothing to do with the casts, since they're both unnecessary -- `usLimit` is converted from `unsigned short` to `int` regardless. No. You'll find there's no shortage of implementations where unsigned short promotes to unsigned int, not int. If they do they are not standards compliant. I agree that they should, but that is neither here nor there. unsigned short promotes to unsigned int if signed int cannot represent all possible values of type unsigned short. Consider, for example, a system where short and int have the same range, as do unsigned short and unsigned int. I think you're confusing this with the controversy of "unsigned preserving" vs. "value preserving" promotion rules. Prior to C89, some implementations used "unsigned preserving" rules for promotion, promoting unsigned short to unsigned int regardless of their ranges. The committee chose to mandate "value preserving" promotion rules. This is discussed in section 6.3.1.1 of the Rationale . The choice of value preserving rules is intended to reduce the cases where an operator has one unsigned int operand and one signed int operand, yielding a "questionably signed" result. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <* We must do something. This is something. Therefore, we must do this. Feb 1 '07 #16

 P: n/a On Feb 1, 11:16 am, CBFalconer

 P: n/a On Feb 1, 9:33 am, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote: Peter Nilsson Hence, implementations can only promote unsigned short to unsigned int if the signed int cannot hold all the values of the unsigned short s/can only/must/ -- which is to say, implementations on which unsigned short and unsigned int are the same size. On implementations on which int has more value bits than unsigned short does, the promotion must be to signed int, not to unsigned int. Yes. The only implementations I can think of in which unsigned int and unsigned short are the same size, are ones that have 16 bit int Similar 32 and 64-bit machines are plentiful. -- that or they are DSPs that use the same large size for short and int and long. Are those the implementations you were thinking of in your "no shortage" statement? Nope. Virtually every high end server box I've used has had an implementation where short and int are the same size. Note that gcc is often configurable in that regard. [cf http://src.opensolaris.org/source/xr...r/src/cmd/gcc/ gcc-3.4.3/gcc/glimits.h] -- Peter Feb 1 '07 #18

 P: n/a "Peter Nilsson" San Diego Supercomputer Center <* We must do something. This is something. Therefore, we must do this. Feb 1 '07 #19

 P: n/a Peter Nilsson wrote: > Nope. Virtually every high end server box I've used has had an implementation where short and int are the same size. Note that gcc is often configurable in that regard. Care to name them? -- Ian Collins. Feb 1 '07 #20

 P: n/a Peter Nilsson wrote: On Feb 1, 11:16 am, CBFalconer >... You'll find there's no shortage of implementations whereunsigned short promotes to unsigned int, not int. If they do they are not standards compliant. It may not comply with your standards, but it certainly complies with the C standards. ;-) No it doesn't. Others have quoted the relevant portion in this very thread. -- "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews Feb 1 '07 #21

 P: n/a CBFalconer San Diego Supercomputer Center <* We must do something. This is something. Therefore, we must do this. Feb 1 '07 #22

 P: n/a CBFalconer On Feb 1, 11:16 am, CBFalconer

 P: n/a On 31 Jan 2007 06:50:47 -0800, "PeterOut" wrote: >If I had code like this.unsigned short usLimit=10int a[10], i;for (i=0; i<(int)usLimit; ++i){ a[i]=(int)usLimit;}would it run slower than this?int a[10], i, iLimit=10;for (i=0; i

### This discussion thread is closed

Replies have been disabled for this discussion.