static_cast vs. dynamic_cast and reinterpret_cast

Let's suppose I have an array of a base class, but it's filled with derived classes. I'll use only one derived class, but suppose there are several types.

Code:

---


Edit: wrong! CBase myArray[MY_ARRAYSIZE];

What I meant:  CBase *myArray[MY_ARRAYSIZE];

...

reinterpret_cast<CDerived *>(myArray[i])->derivedFunction();

---

According to the descriptions of the various castings, this is the wrong thing to do since it doesn't "climb the trees" to return the correct pointer (where a pointer to the derived might actually != pointer to the same object's base!)

So I'd want to use dynamic_cast or static_cast instead (static_cast would be good enough for this particular application.)


More importantly, reinterpret_cast is wrong to use in this situation always?

And as a follow up, as a practical matter, if you don't use multiple inheritence, will the results of reinterpret_cast and static/dynamic_cast ever differ on various compilers? I.e. will the base pointer always == the derived pointer?

Quote:

---

Originally posted by Gorgor

Code:

---

CBase myArray[MY_ARRAYSIZE];

---

---

That doesn't make sense. If you have an array of base class objects, then they are base class objects and not derived class objects. Since the derived class generally will be larger in size than the base class, there's no way you could be putting derived class objects into the array that your compiler created full of base class objects.

If you want an array of base class objects whose type is actually of a derived class, you'd need an array of pointers to base, and then you could use the dynamic_cast to get the appropriate derived object later:

Code:

---

CBase* myArray[MY_ARRAYSIZE];
for (int i = 0; i < MY_ARRAYSIZE; i++)
    myArray[i] = new CDerived;

// ...

CDerived* myDerivedPtr = dynamic_cast<CDerived*>(myArray[j]);
if (myDerivedPtr)
    myDerivedPtr->DerivedFunction();

---

Why don't you use polymorphism? This is what it is for.

It's not a good idea to store derived class objects in an array of the type base class since that will truncate (or slice-off) the derived class object's information. You'll need to store pointers-to-objects instead of actual objects as jlou as posted in the example code. However, dynamic_cast only succeeds if there is at least one function declared as virtual (it's sometimes called a "polymorphic cast").

In addition to jiou's and cma's suggestions, RTTI needs to be enable in order to use dynamic_cast.

And in addition to all of this RTTI talk, if you are casting pointers
strored in a container of base class pointers, then you might have
a bad design on your hands.

in addition to what have been said,

Scott Meyers, in his book "More Effective C++" warns of
treating arrays polymorphically.
Polymorphism and pointer arithmetic don't mix and since
array operations almost always involve pointer arithmetic -
you should avoid mixing the two.

And in addition and for completeness...the following FAQ might help as well...

I, of course, made a mistake in my posting. The array I meant to be an array of pointers to base, not of the base class itself.

Code:

---

CBase *myArray[blah];

---

Having said that, and having read the FAQ, I still am looking for an answer. Apparently the return value of an up or downcast from base (pointer) to derived (pointer) or back might yield (properly done) different pointers.

1. Hence, reinterpret_cast is the wrong thing to use to up or downcast. It always returns just the numerical pointer value, and appears to just be a syntax appeaser for the compiler.

2. Static_cast will do this properly for the up (to base) cast, and also properly for the downcast, if the object is actually a derived class. If the object wasn't, you'd get a pointer as if it were, but this might be very bad.

3. RTTI is not an option. This is an embedded product. Therefore dynamic_cast is not an option.

4. In practice and in actual implementation in compilers, if the object does not have multiple inheritence, will the downcasted pointer returned ever actually differ from the upcast, base class pointer? (Or for that matter, actually modify contents in some kind of conversion?)

Quote:

---

Originally posted by Gorgor
4. In practice and in actual implementation in compilers, if the object does not have multiple inheritence, will the downcasted pointer returned ever actually differ from the upcast, base class pointer? (Or for that matter, actually modify contents in some kind of conversion?)

---

Not very sure what you mean exactly. Actually, a pointer is usually a 4-byte container that holds the address to an object. Not matter whether you upcast or downcast, the address it is holding, is always the same. The only different is the behavior of the pointer. When it is upcasted, the pointer only allow access to its public members, including public virtual function which is provided by the derived class. However, when it is downcasted, you are allow to access all public members of the base class and also the public members of the derived class as well.

Hope this helps.

I was sure I had read somewhere that casting such objects to other objects in their heirarchy could change the actual pointer value.

If that is not the case, then how does static_cast differ from reinterpret_cast with respect to pointers to objects?

I suggest geting the standard and reading sections 5.2.9 (static_cast), and 5.2.10 (reinterpret_cast). They go into a lot of detail as to the differences between the two.

One difference is that static_cast will perform conversions of one type to another using the standard conversion operators for the type being converted to, while reinterpret_cast does not.

Regards,

Paul McKenzie

So reinterpret_cast is just a syntax appeaser, telling the compiler to think of this pointer as a pointer to x rather than a pointer to y.

But how would that ever differ from static_cast if both always properly access member functions of base or derived? Descriptions I read are like lawyer talk, they blather a lot without ever saying much. "Reinterpret_cast" is only safe to use for casting back to what it originally was??? WTH is it good for then, other than casting a void pointer passed through some kind of generic callback?


By strict interpretation, I presume my question is that reinterpret_cast is fine, since we are using a pointer that is to base to coerce back to pointer to derived, which we know it actually is. Is that the final answer?

When using Multiple inheritance, the locations of sub objects are different. Using reinterpret_cast will not change the pointer value, so the result will be that the code will access the wrong part of the object.

John

Which, of course, brings us full circle to my subordinate question: The pointer returned IS actually altered.


In the case of multiple inheritence, where B is an A and a C at the same time, the pointer must get changed. Why? If run typing is off (if that has anything to do with working around this issue) casting B* to a C*, then passing into a function that accepts a C* will have to receive a changed numerical value for the pointer variable. Inside that function, the compiler can't know that some of its C*'s are really pointers to a B*, and then do extra offsets from a "normal, pure" C*.

In other words, passing in B* to a function that accepts an A* and another that accepts a C*, well, both functions HAVE to accept different numerical pointers.

This is not the case with single inheritence (regardless of number of ancestors). The pointer is always to the top, "parent-est" object, and pointers to descendents are always handled as offsets from that ultimate parent's numerical address pointer.

And if anyone digs out some document that says you can't make that assumption, then we must assume the pointers might be changed, and thus even for single inheritence, the pointer might get changed, and thus reinterpret_cast is always the wrong thing to use on object pointers, QED.