# Why FORCE_DWORD = 0x7FFFFFFF ?

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

## Recommended Posts

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

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by DemirugJack, you are not wrong.
Excellent [grin]

Quote:
 Original post by DemirugEvery 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.
Yup, I know of and use that rule... but Il still occasionaly see slightly obvious constructs like:

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

1. 1
2. 2
JoeJ
20
3. 3
frob
19
4. 4
5. 5

• 10
• 10
• 12
• 13
• 9
• ### Forum Statistics

• Total Topics
632199
• Total Posts
3004733

×