Greetings! I had the chance to check intel compiler at work and was suprised, that it shows a lot more errors and warnings as microsoft visual studio. But there is one thing I do not understand. If microsoft compiler in visual studio throws an error, i can just click on it and press F1 where I get a detailed information what is wrong. Currently I can only read the short error message from intel compiler and do not know how to resolve that state? For example I have code that compiles just fine at the highest warning level in micstosoft visual studio, it goest like this: CMyWindow* pWin = (CMyWindow*)this; SetWindowLong( hWnd, USERDATA, (LONG)pWin ); The upper line works just fine in Visual Studio but it will not work with Intel compiler. There is an error like #1638 - "something like" meaningles conversion of same tipe. And that's it. If I remove the LONG from pWin I can not compile anymore with Visual Studio. What is wrong? Where could I get a detailed information about the error #1638 like in visual studio? I could just click on the error and press F1, but the microsoft compiler error codes are different like intels. I do not expect intel compiler to be integerated into MSDN but at least a help file to read out the errors? I saw just some html files that do not help me that much at the moment. Thank you in advance!

reinterpret_cast. You'll thank me later.

Greetings!

reinterpret_cast will not work! Warning #1684 or something like that. What I did was:

CWindow* pWindow = (CWindow*)this;
intptr_t address = reinterpret_cast<intptr_t>(pWindow); <<Warrning #1684

p.s.: "Threat warnings as errors = ENABLED".

I need address for SetWindowLong( hWnd, USERDATA, address );

The problem is I can not cast a pointer to a long or intptr_t.

I believe the Intel compiler is trying to tell you that typecasting this is not needed. Its a no-op. Try removing the (CMyWindow*). Assuming your this pointer derives from CMyWindow and there isn't multiple inheritance going on, you don't need the cast.

btw, the operator (CMyWindow*) can generate machine code, same as a reinterpret_cast<>. You're better off with the C++ casts, so you can be more precise about what you are doing. Usually static_cast<> is what you want, or sometimes const_cast<>. I don't even recall the use case for reinterpret_cast<>, I never use it.

Incidentally, I think you can use this instead, and dodge the whole issue:
SetWindowLong( hWnd, USERDATA, (LONG)this );

As for Intel compiler manuals integration... you'll need to take that up with Intel. ; )

*edit*

I just re-read your last post and saw the bit about not being able to type cast this. The short answer is, you're right. With warnings set to max and warnings and errors, I don't think it'll ever let you. Because it isn't safe to do. You may be able to sneak around it with a union though:

union {
CWindowPtr* ptr;
LONG l;
} u;

u.ptr = this;
SetWindowLong(..., u.l, ...);

Greetings!

Thank you very much for the "union" hint! It works just fine, no warnings at all!

Ya know, the job of a programmer is not just to suppress warnings without understanding what's going on ;)

I don't know anything about the Intel compiler, but Visual Studio 2005 will warn you of portability issues for 64-bit platforms when you enable the correct compiler flag. A LONG is only 4 bytes, and you could end up truncating a 8-byte pointer with your code. I would recommend using the window LONG in some other way than storing a pointer (like as an index into a vector/map of pointers).

I'm a bit worried that the Intel compiler won't let you reinterpret_cast a CWindow* to a intptr_t, though. I would definitely look into that.

A LONG will be 8 bytes on a 64bit machine, so he is not truncating the pointer.

Quote:Original post by Quak
A LONG will be 8 bytes on a 64bit machine, so he is not truncating the pointer.

Nope, a LONGLONG is 64 bits and a LONG is always 32 bit regardless of the platform. If you want a long that follows the size of a pointer use LONG_PTR.

Actually, checking the docs I'm surprised to see that there is a function SetWindowLongPtr that takes a LONG_PTR instead of a LONG. Learn something every day :)