"Go" C + + standard conversion operator reinterpret_cast

Original link: http://www.cnblogs.com/ider/archive/2011/07/30/cpp_cast_operator_part3.html reinterpret_cast <new_type > (expression)

The reinterpret_cast operator is used to handle conversions between unrelated types, and it produces a new value that has exactly the same bit as the original parameter (Expressoin).

What is an unrelated type? I didn't find a good document to show what the relationship between types was (except for the inheritance of classes). The latter sentence shows the literal meaning of reinterpret_cast: Re-interpretation (bit of type). Can we really arbitrarily give a bit of a type value to another type as its value? actually otherwise

The IBM C + + guide clearly tells us where reinterpret_cast can, or where it should be used as a conversion operator:

• From a pointer type to an integer type that is large enough
• From an integer type or enum type to a pointer type
• Pointers from one pointer to a function to another for a different kind of pointer to a function
• Pointer to an object from one pointer to another, to a different type
• From a pointer to a class function member to another pointer to a function member of a different type
• From a pointer to a class data member to another pointer to a different type of data member

However, I tested in Xcode, in fact, the use of reinterpret_cast is not limited to the above mentioned several items, any type of pointer can be converted to each other, will not get compile errors. Some of the items listed above may be limited by the use of reinterpret_cast under Linux, or it may be the way IBM recommends us to use reinterpret_cast

So in summary: Reinterpret_cast is used for conversions between arbitrary pointers (or reference) types, and conversions between pointers and integer types that are large enough, from integer types (including enumeration types) to pointer types, ignoring size.

(The so-called "integer type is large enough", depending on the parameters of the operating system, if it is a 32-bit operating system, it needs to be more than (int), or if it is a 64-bit operating system, you need at least a long shape (long). The specific size can be viewed by the sizeof operator).

What is the role of reinterpret_cast

From the top of the reinterpret_cast introduction, you can feel that reinterpret_cast is a very powerful operator, because it can ignore apartheid, casually engage. but like the rules of biology, random hybridization that does not conform to the law of nature will only get a species that cannot survive for long. Arbitrary use of reinterpret_cast between different types, but also after the destruction of the program and can not be used.

For example, the code below
typedef int (*FunctionPointer)(int); 
int value = 21; 
FunctionPointer funcP; 
funcP = reinterpret_cast<FunctionPointer> (&value); 
funcP(value);

I used a typedef to define a pointer type to a function that takes an int type as a parameter. Then I used reinterpret_cast to convert an integer address into the function type and assign the value to the corresponding variable. Finally, I used the shaping variable as a parameter to give the pointer variable to the function.

This process compiler succeeds in compiling the pass, but once run we will get "exc_bad_access" Run error, because we find through the address referred to by FUNCP is not the function entrance.

As a reinterpret_cast, although seemingly powerful, the role is not so wide. The IBM C + + guide, the C + + parent Bjarne Stroustrup FAQ page, and the MSDN Visual C + + also point out that the wrong use of reinterpret_cast can easily lead to unsafe programs. Only the converted type value is converted back to its original type, so that the Reinterpret_cast method is used correctly.

In this way, reinterpret_cast to other types of purpose is to temporarily hide their own what (to be an undercover?) If you really want to use that value, you still need to expose it. So what is the value of its existence in C + +?

The MSDN Visual C + + Developer Center gives its value: It is used to aid the hash function. Below is an example on MSNDN:

                Expre_reinterpret_cast_operator.cppCompile with:/EHSC#include <Iostream>Returns a hash code based on an addressunsigned short Hash (void *p) { unsigned int val = reinterpret_cast<unsigned int> (p); unsigned short) (val ^ (Val >> 16));} using namespace std; int main () {int a[20]; for (int i = 0; i <; i++) cout << Hash (A + i) << ENDL;} //if it's like I'm a 64-bit system, you may need to change unsigned int to unsigned Long to run.              

This code is suitable to embody the idea of hashing, not to do the drill, but at least look at the hash function inside the operation, you can also realize that the operation of the whole is obviously to address the operation more convenient. Storing the shaping values in the collection is also more extensible than storing the address (of course, if the void * extension is also very high), the only possible loss is the transformation of the shaping and the address at the time of the access (which is completely negligible).

However, readability may not be high, so when used in this case, you can use typedef to define a pointer type:
typedef unsigned int PointerType;

It's not even better, when we're running on a 64-bit machine, just change it to:
typedef unsigned long PointerType;

When reinterpret_cast faces the const

The IBM C + + guide states thatreinterpret_cast cannot remove the const modifier as const_cast. What does that mean? The code is also the most intuitive statement:

int main() {typedef void (*FunctionPointer)(int);int value = 21;const int* pointer = &value;//int * pointer_r = reinterpret_cast<int*> (pointer); // Error: reinterpret_cast from type ‘const int*‘ to type ‘int*‘ casts away constnessFunctionPointer funcP = reinterpret_cast<FunctionPointer> (pointer);}

example, we want to convert pointers to const with operators to non-const pointers, as in the previous Const_cast example. But when the practical reinterpret_cast, the compiler directly error organized the process. This reflects the uniqueness of const_cast.

However, there is also a conversion in the example to pay a pointer to the const int to the pointer to the function, and the compilation goes through the compilation, and of course the result will be meaningless as in the previous example.

If we look at it from a different perspective, it seems reasonable. Because
const int* p = &value;
int * const q = &value;

The meaning of these two statements is different, the former is " the content is not variable", the latter is " point to the address immutable" (see here). The pointer to the function should therefore default to the attribute "the content is not mutable".

After all, after the function has been compiled, its operation is fixed there, and the only thing we can do is pass some parameters to the pointer, and we cannot change the process of the compiled function. So from this point of view, the above example using reinterpret_cast from the const int * to the functionpointer conversion becomes reasonable because it does not remove the const-qualified

"Go" C + + standard conversion operator reinterpret_cast