whats up with dynamic_cast, static_cast, and reinterpret_cast?
i don't understand what these do...
dynamic_cast<>
static_cast<>
reinterpret_cast<>
why not just use normal type casting? when i use any of those 3 things, i have compilation problems anyways. thanks for the help. oh yeah, can someone explain to me what the #pragma directive does? thanks!
-christopher bottaro
[email protected]
[email protected]
[email protected]
Re: whats up with dynamic_cast, static_cast, and reinterpret_cast?
Hi,
reason is: the "normal" cast ( (TYPE) x ) covers four different intentions of casting (that actually do three completely different things on Assembler level). The "C++ style" casts were introduced so the programmer can state what he really wants.
There are the following types of a cast:
* type conversion, like "int" to "float": the _contents_ of the variable will be read and converted (according to some type specific rules)
* casting up in class hierarchy (i.e. cast a dereived class pointer to a base class pointer). On ASM level, usually an offset needs to be added or subtracted from the pointer to the class
* casting down in class hierarchy, i.e. from base to dereived class. This is only safe with run-time information about the class hierarchy, and the "true class" of an object. Again, adding or subtractng an offset from class pointer is necessary
* "hard" cast - treat the data as if it were of different type ("assume the bits at this address are integers"). "Nothing" happens at assembly level (since in machine code, all pointers are void *)
* removing "const" modifiers - again, nothng really happens at assembly (it's only to tell the compiler "I know I break const correctness rules here, please don't complain")
Note that only "hard cast" and "conversion" were possible in classic C, and they could easily be separated (if it's a pointer, it's a "hard" cast).
However, in C++ the ((CFoo *) ptr) can mean a lot of different things, depending on the type of ptr.
Errors introduced by wrongly using the C-style cast operator are notoriously hard to track down.
Now, the real answer:
static_cast does a "safe" type cast, based on the type information available at compile time. static_cast allows type conversion, and casting up in class hierarchy
dynamic_cast does a "safe" type cast, using run time type information, to cast down in class hierarchy. (i.e. it's checked at runtime if the CBase * actually points to a CDereived). For dynamic_cast to work, you must enable RTTI (Run time Type Information) in the C++ compiler settings.
reinterpret_cast does a hard cast - "assume the bits.."
const_cast does the const modifier removal.
-------------
Syntax is:
xxx_cast<destination-type>(expression)
but this of course works only in C++.
-------------
#pragma directives are compiler-specific, they are clearly not part of ANSI or whatever standard. More exactly, the "#pragma" itself is standard, but what follows is compiler-dependent. There are various #pragma directives in MSVC++, from supressing certain warnings to specifying which .lib's the module should be linked to.
Helped?
Peter
P.S. "conversion" cast is not an official or common term; I just used it here since it best describes the action taken
[edited to fix minor typos and a major error]
So is reinterpret_cast any different from "old" casts?
Eight web pages, and two forum articles still don't really answer the question, although this explanation seems to do it, thanks!
For use with qsort's callback function:
Code:
int myCompare(void *e1, void *e2)
{
MyClass *c1 = *(MyClass **) e1; // Compare is ptr to ptr to object.
MyClass *c2 = *(MyClass **) e2;
return (some comparison code);
}
So would one use reinterpret_cast here? (Pointers are guaranteed to be to the class that is being qsorted in the array, not any derived or parent version, i.e. it's an array of MyClasses, not of any parent or child of them.)
And: given it's void, wouldn't the old-style cast be acceptable?
Re: So is reinterpret_cast any different from "old" casts?
Quote:
Originally posted by Gorgor
For use with qsort's callback function:So would one use reinterpret_cast here? (Pointers are guaranteed to be to the class that is being qsorted in the array, not any derived or parent version, i.e. it's an array of MyClasses, not of any parent or child of them.)
Oh no!
So you are calling qsort() on an array of MyClasses or pointers to them? If it is an array of MyClasses, qsort() can only be guaranteed to work if MyClasses is a POD (Plain-Old-Data) class (i.e. it is a struct or class consisting of int's doubles, chars, pointers, arrays of these things, etc.). If it contains non-POD items like std::string, CList, vector, etc. or non-trivial constructors, destructors, etc., qsort is not guaranteed to work. Use std::sort to sort objects correctly, not qsort. Not only that, the ugly pointer code you're doing now with qsort would be a thing of the past.
There was a long thread on this in the non-Visual C++ group -- qsort is not guaranteed to sort an array of non-POD objects correctly. As a matter of fact, it totally messed up an array of objects when tested on several compilers, while std::sort worked perfectly.
Regards,
Paul McKenzie
Re: Re: whats up with dynamic_cast, static_cast, and reinterpret_cast?
Quote:
Originally posted by peterchen
Hi,
* casting up in class hierarchy (i.e. cast a dereived class pointer to a base class pointer). Typically, an offset needs to be added or subtracted from the pointer to the class
* casting down in class hierarchy, i.e. from base to dereived class. This is only safe with run-time information about the class hierarchy. Again, adding or subtractng an offset from class pointer is necessary
Can you give me some more information about this offset.
thanks
