Mail Archives: djgpp/2000/01/22/17:31:44
David Cleaver <davidis AT ou DOT edu> writes:
> OK, I'll explain a little 'bit' more. :) I'm writing a program to
> factor numbers, hopefully, very quickly. Now, in order to do this I
> have created a bunch of two dimensional arrays whose elements only
> consist of zero's and one's. Since this is the case, I decided to
> reduce the size of the array from using an int for each zero or one, and
> have packed all the zero's and one's into unsigned char's. As you can
> see, this greatly reduced the amount of storage needed for these
> tables. However, if the char type ever increases in size, my tables
> wouldn't be as tighly packed as possible, so I wanted to know if it was
> ever going to change.
I don't think you need to worry here. AFAIK, `char' is defined to be
the smallest standard integer data type (not counting bitfields), so
even if `char' were increased in size, you wouldn't be able to do much
about it.
Also, judging from the amount of breakage that would result if a
compiler were to change the size, I suspect they'd include provision
for keeping the old behavior (a switch or something).
> Eli, what did you mean by using the "fastest data type" in a for loop?
> What is the fastest data type that you are refering to here? I wouldn't
> mind being able to speed up my program a bit more.
Most machines have one data type that is fastest to operate on,
normally the one that corresponds to the native wordsize. On the 386,
it's the 32-bit int. The 16-bit short, on the other hand, requires a
special instruction prefix to operate on, and each instruction
requires one more cycle than the corresponding 32-bit instruction.
Thus the code generated for `i++' will be both smaller and faster if
`i' is an int rather than a short.
So if `i' were a loop counter, one would want to make it `int' even if
the additional range wasn't needed. The two bytes saved by using
`short' would be negligible, while the speed savings might not be.
Most machines define `int' as the data type which the machine handles
most efficiently, so it's usually your best bet.
> Also, is it ok to store unsigned chars in hex form? I'll give an
> example below:
>
> unsigned char array1[3][3] = {{0x2a, 0xf4, 0x08},
> {0x96, 0xa5, 0x7c},
> {0x8e, 0x59, 0x8b});
>
> Is this ok, or will the compiler complain, or will I even still be able
> to access it like I normally would? Again, thank you(everyone) for
> helping with all my questions.
Yes, it's perfectly legal. Anywhere you want an integer value (even
if it's only the size of a char), you may specify it in decimal,
octal, hex, or character form. So the following are all equivalent,
everywhere (AFAIK):
114, 0x72, 0162, 'r'
--
Nate Eldredge
neldredge AT hmc DOT edu
- Raw text -