Windows platform SDK (solved).
I recently switched from a really old sdk to the newest.
Upon compiling I ran into some compiler errors.
I tracked it down to a few macros that's declared in windef.h, i.e HIWORD, LOWORD etc.
What MS did was to change:
#define HIWORD(l) ((WORD)((DWORD)(l) >> 16))
to
#define HIWORD(l) ((WORD)((DWORD_PTR)(l) >> 16))
Now my compiler complains that DWORD_PTR isn't an integral and hence it can't be shifted. I'm using a fairly recent compiler (Intel v8).
What does the standard say about this?
Should you be able to shift, and, or, xor pointers?
I guess the change has something to do with 64-bit support. But it seems strange that MS did it in a way that created lot's of problems for many compilers.
[Edited by - eq on March 2, 2007 7:49:44 AM]
DWORD_PTR is not a pointer (refer to MSDN).
It's defined as a ULONG_PTR which is declared in BaseTsd.h:
Maybe the Intel compiler has troubles with the __int64 type which is MS specific iirc.
It's defined as a ULONG_PTR which is declared in BaseTsd.h:
#if defined(_WIN64) typedef unsigned __int64 ULONG_PTR;#else typedef unsigned long ULONG_PTR;#endif
Maybe the Intel compiler has troubles with the __int64 type which is MS specific iirc.
Quote:DWORD_PTR is not a pointer
You're right...
I changed the definition of HIWORD etc to the old ones and all compiles and run well (for 32 bit builds).
Quote:Maybe the Intel compiler has troubles with the __int64 type which is MS specific iirc.
It shouldn't use __int64 since I'm compiling a 32-bit app.
Edit: I now changed back to the original and everything works ok!
I guess it must have been some precompiled header magic, screwing things up!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement