Why FORCE_DWORD = 0x7FFFFFFF ?
Author
Hey :)
Thats maybe a silly question...
Why do all DX enum use 0x7FFFFFFF ? Couldn't 0x1FFFF have done the trick ? So I figured that they wanted to leave as much room as possible for their real enum "members" (like someone would create an enum with 0x1FFFF = 131,000+ values anyway - unless it is auto-generated code maybe -) but then, why not use 0xFFFFFFFF ? Maybe they wanted to reserve the last bit for some error code ? I wonder ^^
(BTW if someone doesn't know, this trick enforces that all the enum is at least 32bits, which is most memory efficient (?) amongst possibly other reasons)
Janta
0x7FFFFFFF is a 31 bit value, which would work given that enum is a signed integer in VStudio.
I'm pretty sure its down to a "standard" C/C++ feature tbh. Off the top of my head, I think the compiler is free to pick a suitably sized type for enums were the values aren't specifically stated (or, even if they are, a size that allows at least the maximum specified). Thus some enums could conceivably fit into an 8 or 16 bit format.
That makes it a little bit messy with things like SetRenderState() and SetTextureStageState() as the parameter is declared as a DWORD yet the actual enum used is dependent on the first D3DRENDERSTATETYPE value.
Whilst the various MS-SDK's seems tailored toward VStudio you could use them with other compilers. Other compilers could have different rules, thus you get into a nasty grey area where the same code results in different functionality based on the compiler and nothing else [oh]
Anyway, I could be completely wrong - but thats my take on it [grin]
hth
Jack
I'm pretty sure its down to a "standard" C/C++ feature tbh. Off the top of my head, I think the compiler is free to pick a suitably sized type for enums were the values aren't specifically stated (or, even if they are, a size that allows at least the maximum specified). Thus some enums could conceivably fit into an 8 or 16 bit format.
That makes it a little bit messy with things like SetRenderState() and SetTextureStageState() as the parameter is declared as a DWORD yet the actual enum used is dependent on the first D3DRENDERSTATETYPE value.
Whilst the various MS-SDK's seems tailored toward VStudio you could use them with other compilers. Other compilers could have different rules, thus you get into a nasty grey area where the same code results in different functionality based on the compiler and nothing else [oh]
Anyway, I could be completely wrong - but thats my take on it [grin]
hth
Jack
Jack, you are not wrong.
A c++ compiler can use any data type for an enumeration that has the same or larger range than all elements of the enumeration.
If you don’t define values for the different elements there is a rule, too:
Every elements get’s the value of the elements that is defined before plus 1. If there is no element before it get’s a zero.
A c++ compiler can use any data type for an enumeration that has the same or larger range than all elements of the enumeration.
If you don’t define values for the different elements there is a rule, too:
Every elements get’s the value of the elements that is defined before plus 1. If there is no element before it get’s a zero.
Quote:Original post by DemirugExcellent [grin]
Jack, you are not wrong.
Quote:Original post by DemirugYup, I know of and use that rule... but Il still occasionaly see slightly obvious constructs like:
Every elements get’s the value of the elements that is defined before plus 1. If there is no element before it get’s a zero.
enum D3D10_QUERY{ D3D10_QUERY_EVENT = 0, D3D10_QUERY_OCCLUSION = ( D3D10_QUERY_EVENT + 1 ) , D3D10_QUERY_TIMESTAMP = ( D3D10_QUERY_OCCLUSION + 1 ) , D3D10_QUERY_TIMESTAMP_DISJOINT = ( D3D10_QUERY_TIMESTAMP + 1 ) , D3D10_QUERY_PIPELINE_STATISTICS = ( D3D10_QUERY_TIMESTAMP_DISJOINT + 1 ) , D3D10_QUERY_OCCLUSION_PREDICATE = ( D3D10_QUERY_PIPELINE_STATISTICS + 1 ) , D3D10_QUERY_SO_STATISTICS = ( D3D10_QUERY_OCCLUSION_PREDICATE + 1 ) , D3D10_QUERY_SO_OVERFLOW_PREDICATE = ( D3D10_QUERY_SO_STATISTICS + 1 ) }D3D10_QUERY;Was never to sure why they bothered with that [smile]
Cheers,
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
