Does reinterpret_cast store a copy of object pointer?

when a reinterpret_cast is applied to a 开发者_如何学运维class object, it returns a LONG_PTR. is it some sort of handle to a temporary object pointer stored somewhere in memory?

The question's not so well worded. I can't think of any manner of object for which reinterpret_cast<LONG_PTR>(object) would work, assuming LONG_PTR is some pointer type (it's not Standard C++), and object is a class instance (the C++ Standard considers variables of built in types to be objects too - that could work).

You may be thinking of:

My_Class my_object;

// convert an arbitrary value to a pointer
reintrepret_cast<LONG_PTR>(1234)

In this case, 1234 is never a run-time "object" - not even a temporary int in memory - it's just a number that the compiler converts to a LONG_PTR as if you'd used static_cast<>. You can think of this as "give me a LONG_PTR with this value".

You could reinterpret to a reference-to-object:

// get a LONG_PTR extracted from memory [&my_object...&my_object+1)
reintrepret_cast<LONG_PTR&>(my_object);

In this case, the pointer returned doesn't necessarily refer to any object that your program has, or even to memory that your program can access. There is no temporary created there for your convenience (as per your question). You're simply telling the compiler that sizeof(LONG_PTR) bytes starting at the base address of my_object ought to contain a LONG_PTR. Hopefully my_object or other code has set it somehow to point somewhere useful, or to a recognisable sentinel value like NULL. Think of this as "give me a reference to the LONG_PTR bits already stored in the front of my_object, letting me treat them as a LONG_PTR and forget all about my_object" - you'd better hope those bits/bytes are aligned in memory in a way your CPU can handle, or you could get SIGBUS or equivalent.

You can also reinterpret a pointer-to-object to a LONG_PTR

// get LONG_PTR that points at my_object's base address
reintrepret_cast<LONG_PTR*>(&my_object);

In this case, you know the returned value does point somewhere in your program, to valid memory, although if sizeof(LONG_PTR) is greater than sizeof(my_object), then not all the memory it addresses is within my_object: any remainder could be from another variable, the stack, or again be inaccessible. Think "give me a LONG_PTR aimed at my_object's memory, which should (or will if you write to it) hold the -value- that a LONG_PTR normally addresses (perhaps a "LONG", or perhaps LONG_PTR is a generic pointer of a particular bit-size?)".

Note these are all very different.

More generally, reinterpret_cast returns whatever type you pass as a template argument, which may or may not be your LONG_PTR, but there's certainly nothing inherently in reinterpret_cast<> that relates to your LONG_PTR type.

reinterpret_cast is used to reinterpret the value written in the memory at the location pointed to your pointer as another type of object. The memory pointed by the pointer remains the same, the only thing that changes is how you interpret the value written.

Also, I would like to remember that usually reinterpret_cast is evil, and must be avoided except there is really no other option.

LONG_PTR is not a standard type and reinterpret_cast<>() is not even a real function but something that will take place a compile time.

So no, nothing happens in memory.

$5.2.10/1

"The result of the expression reinterpret_cast(v) is the result of converting the expression v to type T. If T is a reference type, the result is an lvalue; otherwise, the result is an rvalue and the lvalue-torvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are performed on the the expression v."

So the answer to your question is that it depends on if 'v' is an lvalue or 'rvalue.