Ulong_ptr

This is a discussion on Ulong_ptr within the C++ Programming forums, part of the General Programming Boards category; What is the typedef for ULONG_PTR?...

  1. #1
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630

    Ulong_ptr

    What is the typedef for ULONG_PTR?

  2. #2
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    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.

  3. #3
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630
    Thanks for telling me that Daved!
    Its unsigned long..

    Code:
    someclass *test = new someclass();
    unsigned long test_up = reinterpret_cast<unsigned long>(test);
    Why does MSVC give error with that?
    How can I 'hide' it?

  4. #4
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    What is the error? What do you mean by 'hide'? What, in detail, are you trying to do?

  5. #5
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630
    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..

  6. #6
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    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.

  7. #7
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630
    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.

    Why?
    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..

  8. #8
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    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.

  9. #9
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630
    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();

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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!
    CornedBee

    "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

  11. #11
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    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
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21