• Advertisement

Archived

This topic is now archived and is closed to further replies.

int, float, long, DWORD, all the same size?

This topic is 5551 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

i thought a long was a integer with a bigger capacity, float had more bytes, and DWORD was a big honkin variable. but they are all 4 bytes??? in otherwords, if you declare a variable as a long it has the same maximum value as a variable defined as int?

Share this post


Link to post
Share on other sites
Advertisement
''int'' is generally a type whose size equals the size of the word on a particular processor.

thus, on dos/win16 int is 2 bytes long, and on win32 it''s 4 bytes long.

for dos/win16 architectures, long used to refer to a doubleword, and was 4 bytes long. on win32, it''s still a referred to as a doubleword, following the convention that a word is two bytes long, even though technically a word on 32-bit processor is 4 bytes long. long kept its 4 byte length.

so, int and long on win32 have the same size.

Share this post


Link to post
Share on other sites
if you really want an int to be 16-bit, do this:
short int a_variable;

this comes out to a 16-bit value and on both 16 and 32-bit compilers.

long int another_variable;

will be 32-bit on both 16 and 32-bit compilers. Try this program to see how many bytes your compiler gives each variable:

  
#include <iostream>
using namespace std;

int main(void) {

cout << "The size of an int: " << sizeof(int) << "\n";
cout << "The size of a long int: " << sizeof(long) << "\n";
cout << "The size of a short int: " << sizeof(short) << "\n";
cout << "The size of a float: " << sizeof(float) << "\n";
cout << "The size of a double: " << sizeof(double) << "\n";
cout << "The size of a long double: " << sizeof(long double) << "\n";
cout << "The size of a char: " << sizeof(char) << "\n";
cout << "The size of a bool: " << sizeof(bool) << "\n";

return 0;
}

Share this post


Link to post
Share on other sites
Shouldn''t a BOOL variable be 1 bit (I don''t mean byte) long ?

Kamikaze

Share this post


Link to post
Share on other sites
Kamikaze: Nope. Although a bool only stores true/false values, it uses a byte for storage. And a BOOL is only an MS typedef for unsigned char (or something similar, no reference near me now).

nobodynews: Testing the size of a char is superfluous, as sizeof returns the size of its argument in chars, i.e. sizeof(char) will always return 1 regardless of architecture.


The only things guaranteed about the sizes of built-in types are (from memory, don''t quote me on this):
A char is at least 1 byte, and is shorter than or equal to a short int is shorter than or equal to an int is shorter than or equal to a long int.


In the good old days whenever a type was required in a declaration the presence of an int was implicitly assumed whenever necessary, so most people didn''t write short int or long int, but merely short and long. This has been made a standard way of declaring the types short int and long int in both C and C++.


And for all those ugly all-uppercase types (BYTE, WORD, DWORD, BOOL, etc.), they are merely MS typedef for builtin types, with BOOL=unsigned char (possibly int actually, I don''t remember), WORD=unsigned short, DWORD=unsigned int on modern systems.


-Neophyte

Share this post


Link to post
Share on other sites
quote:
Original post by Kamikaze15
Shouldn''t a BOOL variable be 1 bit (I don''t mean byte) long ?

Kamikaze

Since a variable''s address is given in bytes, it''s impossible to address individual bits.

Share this post


Link to post
Share on other sites
quote:
Original post by Neophyte
Kamikaze: Nope. Although a bool only stores true/false values, it uses a byte for storage. And a BOOL is only an MS typedef for unsigned char (or something similar, no reference near me now).
Correct, a BOOL is a typedef, but a bool is a standard type. Its actual length, I think is implementation specific, and is only required to hold one of two possible values.


Share this post


Link to post
Share on other sites
BOOL is typedef for long, thus it''s 4 bytes long. it has high memory overhead (32 bits to store 1 significant bit), but plays nicely with DWORD-aligned structures.

Share this post


Link to post
Share on other sites
quote:
Original post by Neophyte
And for all those ugly all-uppercase types (BYTE, WORD, DWORD, BOOL, etc.), they are merely MS typedef for builtin types

they save typing. would you rather type DWORD or unsigned long? then throw in pointer types, such as PDWORD.

of course, you could always invent your own types with short names. but isn''t it nice that ms already did this for you?

Share this post


Link to post
Share on other sites
Heh. Well, I actually use all uppercase every once in a while, but only for specific purposes, namely the names of constants.
That is a fairly standard naming scheme, and I find MS''s insistence on all-uppercase typenames to be rather ridiculous.

And BTW, the typedefs aren''t there saving typing, but to ease backwards compatibility over older windows platforms. On win32 for instance, LPARAM and WPARAM are both typedef''ed as the same type, but on win3.x an LPARAM takes twice as much space as a WPARAM. On win3.x an WPARAM is a "WORD-PARAM", while LPARAM is a "LONG-PARAM".

-Neophyte

Share this post


Link to post
Share on other sites
quote:
Original post by Neophyte
nobodynews: Testing the size of a char is superfluous, as sizeof returns the size of its argument in chars, i.e. sizeof(char) will always return 1 regardless of architecture.



Thanks, I didn''t know that about sizeof returning the size in chars . I was just being pedantic, and here I learn something new!

Share this post


Link to post
Share on other sites
I think it''s stupid to append a variable''s address in bytes,
Everything should work on bits, as it is the smaller size, and
less memory would be necessary to allocate to a BOOL variable,
that''s just an example... So creating a BOOL variable is the same
as creating a BYTE variable, I really think that''s a waste of memory...


Kamikaze

Share this post


Link to post
Share on other sites
quote:
Original post by Kamikaze15
I think it''s stupid to append a variable''s address in bytes,
Everything should work on bits, as it is the smaller size, and
less memory would be necessary to allocate to a BOOL variable,
that''s just an example... So creating a BOOL variable is the same
as creating a BYTE variable, I really think that''s a waste of memory...

Kamikaze

Sure, but then your pointers would have to be eight times as big, and 32 bytes for a pointer seems rather too large ... There might be speed issues as well, but this is reason enough, if you ask me.

Share this post


Link to post
Share on other sites
Kamikaze, the reason is that the more specific you get, the slower everything runs. For example, there are three ways of copying memory (hardware version of memcpy) or setting memory (hardware version of memset): one byte at a time, two bytes at a time, or four bytes at a time.

The four-byte is the fastest, the one-byte is the slowest. Things run faster when you use large element sizes. Addressing single bits will be very slow, and it''s not at all important. Why? Well, although only 1 bit is needed for a bool, who cares? You might possibly get as much as 6 bytes of RAM wasted at any given moment. Obviously that is unimportant.

In fact you should consider not even using bytes for boolean values, and using 32-bit integers instead, due to faster memory addressing. In fact, with 32-bit color depth, the highest byte is completely wasted (except for textures with alpha-blending) but it allows for much faster reading/writing than 24-bit mode.

The only exceptions are very large files and network packets, where you can pack the bits for several variables into shared bytes. Example: To save video memory, 16-bit mode is often used instead of 32-bit or 24-bit mode. That''s two bytes, but the first five bits of one byte is used for red, the other 3 bits and the first 3 bits of the other byte are used for green, and the remaining five bits are blue.

~CGameProgrammer( );

Share this post


Link to post
Share on other sites
quote:
Original post by Kamikaze15
Everything should work on bits, as it is the smaller size, and
less memory would be necessary to allocate to a BOOL variable,
that''s just an example... So creating a BOOL variable is the same
as creating a BYTE variable, I really think that''s a waste of memory...
Yes, in a way. But only if you use many booleans, in which case you shouldn''t declare separate bool variables anyway, and rather pack them in longs or other bitfield structs. Actually, the compiler might just do that for you (if you use bool rather than BOOL).

quote:
Original post by Miserable
Sure, but then your pointers would have to be eight times as big, and 32 bytes for a pointer seems rather too large ...
No, a pointer to address all individual bits (while being able to address the normal 4 gig address space) would need to be 35 bits. 32 (2^32-1 = 0xffffffff) to address the byte, and 3 (2^3-1 = 0x7) to address each byte''s bits.


Share this post


Link to post
Share on other sites
quote:
... But only if you use many booleans, in which case you shouldn''t declare separate bool variables anyway, and rather pack them in longs or other bitfield structs. Actually, the compiler might just do that for you (if you use bool rather than BOOL).


the compiler can''t do that for you because it would have problems when you do operations with pointers to those bools...

GA

Share this post


Link to post
Share on other sites
quote:
Original post by ga
the compiler can''t do that for you because it would have problems when you do operations with pointers to those bools...
That is sure a problem. I said the compiiler *might* do it, not that it would. I know that there were compilers that could do that under some circumstances. Personally, I hate compilers that change the "structure" of my code.


Share this post


Link to post
Share on other sites
I personaly use bool instead of BOOL just 'cause it colors to
blue and I like to see the types of variables in a diferent
color, it's easier to read the code, however I use DWORD instead
of unsigned long, just 'cause it's shorter to type.

Sometimes I get a problem with bool and BOOL, sometimes when I
try to make a simple thing like "bool aaa = bbb"(bbb is BOOL),
the compiler says "warning - forcing bool to int, performance
might be affected" or something like that, why does this occurs ???
And if I change the variable "bbb" to BOOL it does not complain
any more... It just happens sometimes, usually I don't get problems
using bool's instead if BOOL's, it just happens sometimes...

Kamikaze

[edited by - Kamikaze15 on December 11, 2002 2:40:59 PM]

Share this post


Link to post
Share on other sites
BOOL b; bool a = b;

Remember that BOOL is a typedef for unsigned long, so it is simply a 32-bit integer. The compiler doesn''t know it''s supposed to be a boolean, it just sees a 32-bit integer. Since a is only either true or false, in order to convert b to a, the compiler puts a conditional jump in the code, which is basically an if statement. So it executes "if b != 0 then a=1; else a=0;". That is slower than a regular variable assignment.

You can avoid the warning by typing the conditional statement yourself:

BOOL b; bool a = b ? true : false;


~CGameProgrammer( );

Share this post


Link to post
Share on other sites

  • Advertisement