What is the typedef for ULONG_PTR?
What is the typedef for ULONG_PTR?
You should be able to find that out on your own. You can right-click inside visual studio and select Go To Definition or Go To Declaration. If those don't work, you can search ULONG_PTR typedef in google or msdn.
Thanks for telling me that Daved!
Its unsigned long..
Why does MSVC give error with that?Code:someclass *test = new someclass(); unsigned long test_up = reinterpret_cast<unsigned long>(test);
How can I 'hide' it?
What is the error? What do you mean by 'hide'? What, in detail, are you trying to do?
I meant warning:
: warning C4311: 'reinterpret_cast' : pointer truncation from 'test *' to 'unsigned long'
What I want to do?
I want to use unsigned long instead of ULONG_PTR but I get warning with unsigned long..
I was hoping for more detail than that. Obviously you could always ignore the warning. If the size of the pointer and the size of the unsigned long are the same then it might not be a problem. Does using ULONG_PTR give the same warning?
You'll probably want to give a lot more detail onwhat you are trying to do to get good advice on the subject. Not just what you are trying to do with that specific line of code, but why you are casting, why you want to store a pointer in an unsigned long, etc.
ULONG_PTR doesnt give a warning. The API that I use requires ULONG_PTR not unsigned long, but I prefer not to use 'foreign' typedefs.
I want to store a pointer in unsigned long because I use it as a key for a class.
I work with IOCP framework, and I have a map with key (pointer in unsigned long ) and smart pointer of the class, and a raw pointer is being passed to the API function.
When I want to remove class from the list, I just get key of the raw pointer, find it in a map, and remove smart pointer. Its the best way I guess..
It appears that VC++ is warning you of potential issues on 64 bit platforms. Basically, if you use the same code on a platform that uses 64 bit pointers, your cast could lose some data. Most likely, you are still using a machine with 32 bit pointers, so this should not be a problem right now. VC++ is just warning you that it might be a problem later.
One solution is to use unsigned __int64 instead of unsigned long. The problem with this is that __int64 is not a standard type, so you are using a "foreign" type.
Another "solution" is to ignore the warning and just make sure that your code will never be run on 64 bit platform. You can ignore all 64 bit related warnings by going to the project properties and selecting "No" under C/C++->General->Detect 64-bit portability issues.
You could also create your own typedef just like ULONG_PTR but defined in your own code so that it is not a "foreign" type. If _WIN64 is defined you could force an error or use the __int64 or whatever you choose to do.
Is there a reason you can't use the pointer directly as the key for the class? Is the map part of the IOCP framework and does it require a non-pointer key? You can use a pointer as the key to a standard library map.
So its the best to just use ULONG_PTR where needed..
What about char when receiving data? Should I use BYTE instead char when working on 64bit systems?
Maybe I could just use raw pointer as key in the map?
So when API returns raw pointer, I can just map[raw_pointer] and I get smart pointer? Would that be smart or it could interrupt smart pointer?
Raw pointer is actually just boost smart_pointer.get();
Pointers are not fully orderable according to the standard, so using them as keys in a map is not valid.
(It works in practice. Just saying.)
In general, use whatever types the API wants. Not wanting to use the API's types if you're already using its functions is misplaced ... something. Misplaced, in any case.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
If you don't want to use ULONG_PTR in one part of the code, but have to use it in the other that is dependedn on some external API, that you can replace in the future - make you own typedef for the ULONG_PTR, use this new type as a base for your map in the code that will not change...
In this case if you change the external API and instead of ULONG_PTR the key value will be for example long long int - you just replace your typedef and the part of the code dealing with the map is leaved untoched
To be or not to be == true