About conversion between pointers - c++

Question

What does actually "conversion between pointers" mean ? If I have something like type_1* x, type_2* y and call dynamic_cast<type_1*>(y) (the question is not about dynamic cast, I used it because it is a function that works well with pointers casting as far as I know) what will it return ? A pointer of type *type_1 that points to the same object as y (or NULL, of course) ? Is this true? Is there anything more I should know to understand these castings between pointers ?

Answer 1

In case of classes and multiple inheritance, casting pointers can change the value (address) of the pointer as well.
Observe:
#include <iostream>
class Foo {
int foo;
};
class Bar {
double bar;
};
class Baz: public Foo, public Bar {
short baz;
};
int main() {
Baz bz;
std::cout << &bz << " " << static_cast<Bar *>(&bz) << " " << static_cast<Foo *>(&bz) << std::endl;
}
That's because the instances of the parent types are at different offsets of the derived object, they can't both sit at the same address.
This is upcasting (child to parent) which is always legal and static_cast is enough, for downcasting (parent to child) the extra checking of dynamic_cast is needed.

Answer 2

What does actually "conversion between pointers" mean ?
It means a conversion from pointer of one type to another pointer type.
what will [dynamic_cast<type_1*>(y)] return ? A pointer of type *type_1 that points to the same object as y (or NULL, of course) ? Is this true?
That is true. The "same object" is correct in an Object Oriented sense. Although from strict C++ sense, the pointed objects of different types may be considered to be different objects.
Is there anything more I should know to understand these castings between pointers ?
Yes, this is not the full extent of the rules relating to pointers and conversions. I recommend reading the documentation thoroughly and possibly some C++ books, in order to understand pointers and conversions.

Answer 3

Some time ago I saw the code that controlled the first Apollo mission. It was all-assembly, the C, lat alone C++, did not exist at those days. We can imagine that in that assembly, all they had at their disposal was registers and raw memory that had to be managed manually.
In modern, non-assembly languages, including C/C++, the compiler frees you from the burden of manual memory management. The memory for named variables, like in
int x = 0;
is allocated and deallocated automatically. Also, you don't need to bother about memory that is needed temporarily, e.g., during some complex computations. In C/C++ these "usual" variables are accompanied by pointers that allow you to access this automatically or semi-automatically managed memory indirectly. Moreover, you need pointers to access the heap-allocated ("nameless") memory (remember operator new?). And this is almost all you should know about them. The syntax is known: the asterisk *, the "arrow" -> and the ampersand &. It's the compiler's duty to protect you from doing probably stupid operation on pointers, like using them as if they are just integers (a popular trick in 1970s) or using them as if they pointed to something else that you've declared. Declaring a pointer means that you declare the whole set of operations on it. To protect you from accidental shooting your foot off, the compiler forbids such horrible things like automatic assignments of pointers of different types.
However, you are the master of the compiler, not the opposite, so you can take the full control. This is where pointer conversion steps in. On the one hand, by ussing pointer conversion, you can temporarily switch off all the safeties the creators of the compiler has prepared for you. On the other hand, with a suitable cast, you can guarantee that your program is correct!
The really important question is: which operations involving pointer conversions are guaranteed to be safe?
The first, a bit surprising thing is: there are several types of pointers, which need not be mutually compatible:
pointer to data
pointer to (free) function
pointer to data member
pointer to member function
void* pointer
Their internal representation, or even the number of bits they occupy, need not be the same!
So, what is allowed?
The C language loves to use void* as the means of passing data of arbitrary type. So you can be sure that you can convert any data pointer to void* and then back to its original type and this will work. Similarly with pointers to functions.
Another place where pointer conversions are natural is low-level serialization. Many function in both C and C++ work on buffers declared as char* or const char*. From this you can infer that you should be able to convert any pointer to data to char* and it will work as expected.
The third common pointer conversion is when you deal with inheritance, especially in the context of classes with virtual functions. Here comes dynamic_cast to cast a pointer in the potentially "dangerous" way along the inheritance tree.
There are also other casts that are safe and others that may lead to undefined behavior or even segmentation fault. For example, pointers to int are often casts to or from pointers to float and it usually works, e.g., in AVX or GPU programming. Correctness of these particular casts are guaranteed by hardware vendors rather than the C++ standard.
What dangers are there if you leave the land of safe casts? For example, you cast a pointer to function to void* and then this pointer to char*. If you try to dereference this pointer, let alone write through it, your program is doomed to die immediately. Similarly dangerous conversions are between pointers to data and pointers to members. Don't do that. Also, don't use pointers to cast pointers to integers etc. This is generally the land of undefined behavior, unless you carefully consulted the standard and are sure the thing you're doing is safe.
To sum this long story up: pointer conversion usually generates no code, but sometimes it does. See the examples below.
EXAMPLES
1. Inheritance. Static cast vs. dynamic cast.
Suppose we have XY derived from both X and Y:
struct X
{
float x;
};
struct Y
{
float y;
};
struct XY : public X, public Y
{
float xy;
};
Then this code:
XY a;
std::cout << static_cast<X*>(&a) << "\n";
std::cout << static_cast<Y*>(&a) << "\n";
std::cout << reinterpret_cast<X*>(&a) << "\n";
std::cout << reinterpret_cast<Y*>(&a) << "\n";
std::cout << &a << "\n";
may produce these results:
0x7fffc7d75dcc
0x7fffc7d75dd0
0x7fffc7d75dcc
0x7fffc7d75dcc
0x7fffc7d75dcc
So, static_cast does change the "value" of the pointer! At the same time, reinterpret_cast only "reinterprets" the bits stored in a pointer variable / register, but does not modify them.
Interestingly, if we defined a virtual method in Y, the same code would reveal a reversed order of X and Y inside XY:
0x7ffc6a45764c
0x7ffc6a457640
0x7ffc6a457640
0x7ffc6a457640
0x7ffc6a457640
So, the order of embedding the base classes in multiple inheritance seems to be undefined / implementation-dependent.
2. casts to integer types
The standard allows to cast pointers to and from integer types of sufficient length.
Casts of "C-style pointers" to integer types work as expected:
XY a;
std::cout << std::hex << reinterpret_cast<uint64_t>(&a) << "\n";
std::cout << reinterpret_cast<void*>(&a) << "\n";
yields, for example,
7fff84f5a6cc
0x7fff84f5a6cc
as expected. But he standard does not guarantee this.
3. pointers to data members
This case is more interesting: pointers to members cannot be cast to anything. But there's a workaround:
XY a;
float XY::* mptr_xy = &XY::xy;
float XY::* mptr_x = &XY::x;
float XY::* mptr_y = &XY::y;
std::cout << *reinterpret_cast<uint64_t*>(&mptr_x) << "\n";
std::cout << *reinterpret_cast<uint64_t*>(&mptr_y) << "\n";
std::cout << *reinterpret_cast<uint64_t*>(&mptr_xy) << "\n";
This may give the following result:
0
4
8
This shows that the pointers to members are offsets into objects memory rather than pointers to RAM. If we add a virtual destructor to Y we may get this:
12
8
16
The offsets have changed, making room for vptr and moving Y to the front. If both X and Y have virtual destructors, a possible result is this:
8
24
28
Conclusion: pointers to members are completely different beasts than standard pointers.
4. Dynamic casts
Suppose both X and Y have virtual destructors. This code:
XY xy;
Y y;
std::cout << "xy:\n";
std::cout << &xy << "\n";
std::cout << dynamic_cast<Y*>(&xy) << "\n";
std::cout << dynamic_cast<Y*>(dynamic_cast<X*>(&xy)) << "\n";
std::cout << dynamic_cast<X*>(&xy) << "\n";
std::cout << "y:\n";
std::cout << &y << "\n";
std::cout << dynamic_cast<XY*>(&y) << "\n";
std::cout << dynamic_cast<Y*>(dynamic_cast<XY*>(&y)) << "\n";
std::cout << dynamic_cast<Y*>(reinterpret_cast<XY*>(&y)) << "\n";
std::cout << dynamic_cast<Y*>(static_cast<XY*>(&y)) << "\n";
may produce this output:
xy:
0x7ffc0a570590
0x7ffc0a5705a0
0x7ffc0a5705a0
0x7ffc0a570590
y:
0x7ffc0a570580
0
0
0x7ffc0a570590
0x7ffc0a570580
Casts of the address of xy may give 2 different results.
Casts of the address of y may give 3 different results.
Summary:
Pointer casts in C++ are far more complex than in C. The standard only guarantees behavior, but not the implementation. So, for example, a cast to an integer type might involve some bit manipulation - existing implementations don't do this because there's no point in doing this, not because it's forbidden. The main differences arise from C++ having multiple inheritance, virtual function and pointers to members.
Caveat. This long reply did not cover all aspects of pointer casts, most notably data alignment. Also, the standard does not impose any limitation on the implementation of various pointers, and even the reinterpret_cast is not guaranteed to preserve the internal bit representation:
Unlike static_cast, but like const_cast, the reinterpret_cast expression does not compile to any CPU instructions (except when converting between integers and pointers or on obscure architectures where pointer representation depends on its type).
https://en.cppreference.com/w/cpp/language/reinterpret_cast
See also:
https://en.cppreference.com/w/cpp/language/explicit_cast
https://en.cppreference.com/w/cpp/language/const_cast
https://en.cppreference.com/w/cpp/language/dynamic_cast
https://en.cppreference.com/w/cpp/language/static_cast
https://en.cppreference.com/w/cpp/language/implicit_conversion

Answer 4

what does casting between pointers mean ?
You change the meaning of the same data / object.
Example 1:
class Base {
public:
void food() {printf("foo\n");}
}
class Derived : public Base {
public:
void bar() {printf("bar");}
}
int main() {
Base * base = new Derived();
base->foo(); // OK, it compiles
base->bar(); // **NOK, syntax error**, even if you instantiated Derived class
Derived * derived = static_cast<Derived *>(base);
derived->foo(); // OK, it compiles
derived->bar(); // OK, it compiles
return 0;
}
Example 2:
int main() {
char word[] = {'W', 'o', 'r', 'd', '\0', '\0', '\0', '\0'}; // array of 8 chars
const char * ptrChar = static_cast<const char *>(word); // cast to "const char* "
const int * ptrInt = reinterpret_cast<const int *>(word); // cast to "const int* "
int lenChar = 0
while (ptrChar[lenChar] != 0)
++ lenChar;
printf("lenChar = %d\n", lenChar); // lenChar = 4
int lenInt = 0;
while (ptrInt[lenInt] != 0)
++ lenInt;
printf("lenInt = %d\n", lenInt); // lenInt = 1
return 0;
}
etc....
You should "play" more with pointers then you'll understand more about pointers and sense of conversion. It is a huge topic and essential in C/C++
dynamic casting is more complex. It requires understanding of run-time and compile-time, polymorphism, hierarchy, etc. In these 2 examples i didn't use dynamic casting because it would not work.