Author |
Message |
Scott Fortne #1 / 10
|
Why use DWORD
I am going through MS SDK examples for DirectX to use in a .net C++ managed project. They make a lot of use of the data type DWORD. A dword is just an 32bit unsigned integer. Is there any good reason to continue using dword instead of int or uint? Thanks.
|
Sat, 08 Jan 2005 11:52:49 GMT |
|
|
Jason Barlo #2 / 10
|
Why use DWORD
Portability. You cannot guarantee that unsigned int will be 32 bits on all Windows platforms. This, in fact, is very much the case these days since 64-bit Windows is a reality. By using DWORD in your applications, you will always know that you are operating on 32-bits regardless of your target platform. J
Quote: > I am going through MS SDK examples for DirectX to use in a .net C++ managed > project. They make a lot of use of the data type DWORD. A dword is just an > 32bit unsigned integer. Is there any good reason to continue using dword > instead of int or uint? Thanks.
|
Sat, 08 Jan 2005 12:35:48 GMT |
|
|
Carl Danie #3 / 10
|
Why use DWORD
Actually, on Win64, int (and DWORD) are still 32 bits, while DWORD_PTR is 64 bits (IIRC). If you want a 32-bit integer, and don't care about portability outside MS tools, you can use __int32. The main reason to use DWORD is for API compatibility - 1000's of Win32 API functions have parameters of type DWORD or DWORD* - for those functions, you _should_ be using variables of type DWORD in your code to remain portable to future Windows versions (and Win64). Within your own "pure" code (code which doesn't interact with Windows), IMO it's better to NOT use typedefs like DWORD - using them reduces the portability of your code to non-Windows platforms. If you insist on using a typedef for 32-bit integer, make your own - that way if you do port to another compiler/os, you'll only have to fix it one place. -cd
Quote: > Portability. You cannot guarantee that unsigned int will be 32 bits on all > Windows platforms. This, in fact, is very much the case these days since > 64-bit Windows is a reality. By using DWORD in your applications, you will > always know that you are operating on 32-bits regardless of your target > platform. > J
> > I am going through MS SDK examples for DirectX to use in a .net C++ > managed > > project. They make a lot of use of the data type DWORD. A dword is just > an > > 32bit unsigned integer. Is there any good reason to continue using dword > > instead of int or uint? Thanks.
|
Sat, 08 Jan 2005 21:27:26 GMT |
|
|
Jason Barlo #4 / 10
|
Why use DWORD
As a general rule of thumb I would agree - use your own typedef's for non-system-specific code. However, Scott specifically mentioned the DirectX API's - unlikely he is looking to develop his Direct3D application on Linux :) In those cases, I would recommend he follow the signatures as declared to avoid portability issues with future/existing versions of Windows or the DirectX API. Ideally, one would localize such code in a single module allowing one to port that layer to another framework (i.e. OpenGL) with minimal impact. For all other types appearing in my "non-OS-specific" code, I would elect to follow a more portable data by formulating my own system of typedefs, always aware that an integer may or may not be 32-bits (among other things). J
Quote: > Actually, on Win64, int (and DWORD) are still 32 bits, while DWORD_PTR is 64 > bits (IIRC). > If you want a 32-bit integer, and don't care about portability outside MS > tools, you can use __int32. > The main reason to use DWORD is for API compatibility - 1000's of Win32 API > functions have parameters of type DWORD or DWORD* - for those functions, you > _should_ be using variables of type DWORD in your code to remain portable to > future Windows versions (and Win64). > Within your own "pure" code (code which doesn't interact with Windows), IMO > it's better to NOT use typedefs like DWORD - using them reduces the > portability of your code to non-Windows platforms. If you insist on using a > typedef for 32-bit integer, make your own - that way if you do port to > another compiler/os, you'll only have to fix it one place. > -cd
> > Portability. You cannot guarantee that unsigned int will be 32 bits on > all > > Windows platforms. This, in fact, is very much the case these days since > > 64-bit Windows is a reality. By using DWORD in your applications, you > will > > always know that you are operating on 32-bits regardless of your target > > platform. > > J
> > > I am going through MS SDK examples for DirectX to use in a .net C++ > > managed > > > project. They make a lot of use of the data type DWORD. A dword is > just > > an > > > 32bit unsigned integer. Is there any good reason to continue using > dword > > > instead of int or uint? Thanks.
|
Sat, 08 Jan 2005 22:05:58 GMT |
|
|
Andrew Bolstridg #5 / 10
|
Why use DWORD
actually, I find its easier to use DWORD types when porting - you know what size this type is on Windows, obviously, and for other platforms, simply #define DWORD to the correct type for the other platform. DWORD_PTR will be 64 bits on Win64 as its a pointer to a DWORD, isn't it? Cheers, Andy.
Quote: > Actually, on Win64, int (and DWORD) are still 32 bits, while DWORD_PTR is 64 > bits (IIRC). > If you want a 32-bit integer, and don't care about portability outside MS > tools, you can use __int32. > The main reason to use DWORD is for API compatibility - 1000's of Win32 API > functions have parameters of type DWORD or DWORD* - for those functions, you > _should_ be using variables of type DWORD in your code to remain portable to > future Windows versions (and Win64). > Within your own "pure" code (code which doesn't interact with Windows), IMO > it's better to NOT use typedefs like DWORD - using them reduces the > portability of your code to non-Windows platforms. If you insist on using a > typedef for 32-bit integer, make your own - that way if you do port to > another compiler/os, you'll only have to fix it one place. > -cd
> > Portability. You cannot guarantee that unsigned int will be 32 bits on > all > > Windows platforms. This, in fact, is very much the case these days since > > 64-bit Windows is a reality. By using DWORD in your applications, you > will > > always know that you are operating on 32-bits regardless of your target > > platform. > > J
> > > I am going through MS SDK examples for DirectX to use in a .net C++ > > managed > > > project. They make a lot of use of the data type DWORD. A dword is > just > > an > > > 32bit unsigned integer. Is there any good reason to continue using > dword > > > instead of int or uint? Thanks.
|
Sun, 09 Jan 2005 00:35:12 GMT |
|
|
Carl Danie #6 / 10
|
Why use DWORD
Quote: > actually, I find its easier to use DWORD types when porting - you know what > size this type is on Windows, obviously, and for other platforms, simply > #define DWORD to the correct type for the other platform.
That can be the case, sure. It can also be really annoying if code has made extensive use of the 30+ typedefs Windows uses for simple types in ways that aren't really appropriate. Quote: > DWORD_PTR will be 64 bits on Win64 as its a pointer to a DWORD, isn't it?
Not a pointer to a DWORD, but an "unsigned integer that's large enough to hold a pointer". It exists solely for situations which require casting a pointer to an integer type that's compatible with both Win32 and Win64. -cd
|
Sun, 09 Jan 2005 00:56:43 GMT |
|
|
Scott Fortne #7 / 10
|
Why use DWORD
Thanks.
Quote:
> > actually, I find its easier to use DWORD types when porting - you know > what > > size this type is on Windows, obviously, and for other platforms, simply > > #define DWORD to the correct type for the other platform. > That can be the case, sure. It can also be really annoying if code has made > extensive use of the 30+ typedefs Windows uses for simple types in ways that > aren't really appropriate. > > DWORD_PTR will be 64 bits on Win64 as its a pointer to a DWORD, isn't it? > Not a pointer to a DWORD, but an "unsigned integer that's large enough to > hold a pointer". It exists solely for situations which require casting a > pointer to an integer type that's compatible with both Win32 and Win64. > -cd
|
Sun, 09 Jan 2005 02:33:31 GMT |
|
|
Alan Kruege #8 / 10
|
Why use DWORD
Quote:
> > DWORD_PTR will be 64 bits on Win64 as its a pointer to a DWORD, isn't it? > Not a pointer to a DWORD, but an "unsigned integer that's large enough to > hold a pointer". It exists solely for situations which require casting a > pointer to an integer type that's compatible with both Win32 and Win64.
Ugh, that's horribly non-intuitive. I'm sure Andrew (and myself) are not the only ones who will misinterpret the meaning of that name. I'm sure even now that I know what it means, I'll make this same mistake again in the future because the name is a misnomer. UINT_PTR would have been closer to what was intended. At least UINT implies an unsigned integer, which doesn't imply the size of the type, while DWORD is supposed to imply a double-word, with specific size.
|
Sun, 09 Jan 2005 03:47:17 GMT |
|
|
Carl Danie #9 / 10
|
Why use DWORD
Quote:
> > > DWORD_PTR will be 64 bits on Win64 as its a pointer to a DWORD, isn't > it? > > Not a pointer to a DWORD, but an "unsigned integer that's large enough to > > hold a pointer". It exists solely for situations which require casting a > > pointer to an integer type that's compatible with both Win32 and Win64. > Ugh, that's horribly non-intuitive. I'm sure Andrew (and myself) are not > the only ones who will misinterpret the meaning of that name. I'm sure even > now that I know what it means, I'll make this same mistake again in the > future because the name is a misnomer. > UINT_PTR would have been closer to what was intended. At least UINT implies > an unsigned integer, which doesn't imply the size of the type, while DWORD > is supposed to imply a double-word, with specific size.
Tell me about it! At least I can smugly say "it wasn't my idea" :) I believe UINT_PTR is also defined, come to think of it (don't quote me on that though). -cd
|
Sun, 09 Jan 2005 04:19:12 GMT |
|
|
Craig Power #10 / 10
|
Why use DWORD
Quote:
> I believe UINT_PTR is also defined, come to think of it (don't quote > me on that though).
It is, as are INT_PTR, LONG_PTR, and ULONG_PTR. FWIW, in the same header, there are INT32, LONG32, and DWORD32, and corresponding INT64, LONG64, and DWORD64.
|
Sun, 09 Jan 2005 21:42:11 GMT |
|
|
|