quote:Original post by Mage2k
Hmmm.... Don''t most compilers these days default to long for ints these days anywayz? A quick check with gcc does, and I''m pretty sure that VC++/NET does also. If you want the smaller representation, specify short. Also, a single char may be padded, but I would think that an array of chars will be packed in together (with maybe some padding at the end) which is how I usually see this done.

unsigned char keys[256;

peace and (trance) out

Mage

Yes, ints are 32-bit. And I did a quick google search and found that almost all compilers do pad. If it is an array, they wouldn''t, because of pointer math (address[offset]), but they would probably pad at the end.

quote:Original post by Ready4Dis
Sorry, you are correct..

bool == char (1 byte), I was thinking BOOL .

Since the OP did not specify what particular environment we are talking about, we can only assume what the standard guarantees: A bool is at least as large as a char (which is at least 8 bits) and at most as large as a long (which it at least 32 bits). Beyond this we have no guarantees.

With regards to speed, note that an int is typically the same size as a memory word (32 bits on a 32-bit nmachine). This, AFAIK, means that computation with ints is typically always as fast as integer arithmetic will get on your machine (though on the other hand, if your chars are 8 bits and your ints are 32 bits, moving ints around involves four times as much memory to copy). (When I say typically I mean to say that, AFAIK, this can generally be assumed the case, but even this is not guaranteed.)

quote:Original post by Miserable

quote:Original post by Ready4Dis
Sorry, you are correct..

bool == char (1 byte), I was thinking BOOL .

Since the OP did not specify what particular environment we are talking about, we can only assume what the standard guarantees: A bool is at least as large as a char (which is at least 8 bits) and at most as large as a long (which it at least 32 bits). Beyond this we have no guarantees.

With regards to speed, note that an int is typically the same size as a memory word (32 bits on a 32-bit nmachine). This, AFAIK, means that computation with ints is typically always as fast as integer arithmetic will get on your machine (though on the other hand, if your chars are 8 bits and your ints are 32 bits, moving ints around involves four times as much memory to copy). (When I say typically I mean to say that, AFAIK, this can generally be assumed the case, but even this is not guaranteed .)

Sorry! I didn't say it in the original post, but I said I used VC++.NET in a later reply. And, as I said, a bool is 1 byte according to its help file. But, because of padding, I will just use ints. Thanks a lot for all of your (quick) input!


[edited by - PlayGGY on December 13, 2003 12:20:53 AM]

[edited by - PlayGGY on December 13, 2003 12:23:26 AM]

This is premature optimization. Use whatever makes sense. If you are reading/writing binary data (from a file or socket say) then you don't want to use just ints. But if you're dealing with numbers then using ints universally isn't really a big deal I think.

Don't try to replace bools with ints though. Some people in the D language do that (but use the bit datatype), its rather asinine.

[edited by - antareus on December 14, 2003 1:03:25 AM]

quote:Original post by antareus
This is premature optimization. Use whatever makes sense. If you are reading/writing binary data (from a file or socket say) then you don''t want to use just ints. But if you''re dealing with numbers then using ints universally isn''t really a big deal I think.

Don''t try to replace bools with ints though. Some people in the D language do that (but use the bit datatype), its rather asinine.

[edited by - antareus on December 14, 2003 1:03:25 AM]

I am not doing for optimization, as I said, I am doing it to make my code more consistent. And the only thing wrong with replacing bools with ints that I see is now the variable can no longer only have 2 values.