int, float, long, DWORD, all the same size?
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.
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?
Oh, relax, niyaw Neophyte just has a pathological fear of uppercase letters as many C programmers do. I never understood it but whatever.
~CGameProgrammer( );
~CGameProgrammer( );
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
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
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!
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
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
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.
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( );
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( );
quote:Original post by Kamikaze15Yes, 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).
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...
quote:Original post by MiserableNo, 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.
Sure, but then your pointers would have to be eight times as big, and 32 bytes for a pointer seems rather too large ...
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement