«

I've always been a little sketchy on the differences between static,
dynamic, and reinterpret casting. I am looking to clean up the
following block by using C++ casting instead of the C style casting.
from what I am reading, I should use reinterpret cast in this
situation, is that correct? Why does static and dynamic casting fail
me?

// please excuse the windows types, it is necessary in this code,
// but the question remains C++ related

BYTE * textureBuffer = static_cast<BYTE *>(data.pBits);
DWORD colorkey = *((LPDWORD)((DWORD)textureBuffer));

for(unsigned y = 0; y < info.Height; y++)
{
for(unsigned x = 0; x < info.Width; x++)
{
// Get the pixel at the current row and column
// with confidence that there are 4 bytes per pixel
// because we guarenteed earlier that the format
// is A8RG8B8
DWORD * pixel = ((LPDWORD)((DWORD)textureBuffer + y *
data.Pitch + x * 4));
fout << "\t" << std::hex << (*pixel);
}
fout << std::endl;
}

fout.close();

brekehan wrote:
> I've always been a little sketchy on the differences between static,
> dynamic, and reinterpret casting.

static_cast

static_cast is used to perform a cast between related types. Any of the
basic types (char, double, int, etc) can be converted using this cast.
It can also be used to up-cast or downcast classes in the same
inheritance tree (however, review dynamic_cast for reasons why you
might not want to do this). It correctly performs any necessary pointer
movement in order to point at the correct location within the object
for that static type. Consider that static almost always means
something performed at compile time that results in a hard coded
manipulation of the object into a new type.
dynamic_cast

dynamic_cast will perform a run-time cast of a polymorphic type. This
means that it is a safer but slower cast to objects sharing an
inheritance tree. This is usually used for a down cast that checks for
the validity of the cast before continuing. When a dynamic cast is
performed the system checks whether the object of cast is actually of
the type being cast to. Review the following:

class A {}; class B : public A {}; class C : public A {};

....

A * b = new B; A * c = new C;

....

C * bad = static_cast<C>(b); // also the result of a c style cast.

In this case the compiler happily performs the necessary conversion
between the related types B* and C* but the cast is obviously not
valid. Later something could blow up because B and C don't have the
same alignment properties. See the following:

C * bad = dynamic_cast<C>(b); If (bad)...ok.

In this case a dynamic, or run-time cast was used. The result of this
cast is a null pointer because b is not a C* and the cast is not valid.
This can now be checked and validated so that the program doesn't
just crash because someone didn't account for some situation when a
B* could be passed into a function that did this cast.

When this cast is performed on a reference it results in a bad_cast
exception instead of a null pointer.

const_cast

This is rarely necessary. If you need a const cast you should review
why and take the problem to the program manager for review. Do not cast
away constness without this review process.

Const cast is used to cast away constness or volatility. We do not use
volatility currently in pipe-flo so I will focus on constness. Const
cast should NEVER be used unless you are casting TO const. The
following is an example:

const char * x = "hello"; char * y = const_cast<char*>(x);

The goal of the above code is probably to change the text pointed to by
x. This results in undefined behavior and must not be done.

Sometimes one might be tempted to cast away constness in order to call
a non-const function that you are sure won't change anything. The
correct way to fix this problem is to make the function const. There
are a few cases when it is appropriate to change values internal to a
class in a const function (this also must be reviewed by the program
manager) and you can do this by making that variable "mutable".

One situation that const_cast is allowed without review is casting into
const:

class Obj {

...

void f() const { do stuff without changing anything}; void f() { do
something that changes stuff; const_cast<const Obj*>(this)->f(); } };

That uses the const version of f() instead of rewriting the same code.
This is of questionable design but not invalid so is allowed.

reinterpret_cast

This cast is used to cast between totally unrelated types. For
instance, you may have a C function that accepts char* as input and you
want to pass in an array of integers instead (often seen in binary file
output). This would be done as follows:

void cf(const char * input, size_t size);

.... int x[] = {5, 11, 23 }; cf(reinterpret_cast<char*>(x), sizeof(int)
* 3);

Notice that a const cast is not necessary because you can always add
const without a cast.

The above code formally results in undefined behavior but is necessary
when dealing with C code that doesn't have the strong typing and
templates available in C++.

You can always perform a cast from one type to another and back
(assuming that the size of the destination type is large enough to hold
the entire value of the source) and this will result in defined
behavior. For instance, passing data into a C callback (any win32 dlg
proc) you will often want to cast some pointer to the LPARAM type:

reinterpret_cast<LPARAM>(an_integer)

Later you can cast back:

reinterpret_cast<int>(lParam);

This is valid and defined code since the LPARAM type is large enough to
store any int value.

brekehan wrote:
> I've always been a little sketchy on the differences between static,
> dynamic, and reinterpret casting. I am looking to clean up the
> following block by using C++ casting instead of the C style casting.
> from what I am reading, I should use reinterpret cast in this
> situation, is that correct? Why does static and dynamic casting fail
> me?
>
> // please excuse the windows types, it is necessary in this code,
> // but the question remains C++ related
>
> BYTE * textureBuffer = static_cast<BYTE *>(data.pBits);
> DWORD colorkey = *((LPDWORD)((DWORD)textureBuffer));

* reinterpret_cast<LPDWORD>(
reinterpret_cast<char *>(textureBuffer)
)
....

>
> for(unsigned y = 0; y < info.Height; y++)
> {
> for(unsigned x = 0; x < info.Width; x++)
> {
> // Get the pixel at the current row and column
> // with confidence that there are 4 bytes per pixel
> // because we guarenteed earlier that the format
> // is A8RG8B8
> DWORD * pixel = ((LPDWORD)((DWORD)textureBuffer + y *
> data.Pitch + x * 4));
> fout << "\t" << std::hex << (*pixel);
> }
> fout << std::endl;
> }
>
> fout.close();
>

Noah Roberts:

> static_cast
>
> static_cast is used to perform a cast between related types. Any of the
> basic types (char, double, int, etc) can be converted using this cast.
> It can also be used to up-cast or downcast classes in the same
> inheritance tree (however, review dynamic_cast for reasons why you
> might not want to do this). It correctly performs any necessary pointer
> movement in order to point at the correct location within the object
> for that static type. Consider that static almost always means
> something performed at compile time that results in a hard coded
> manipulation of the object into a new type.


I think an exhaustive list of uses for static_cast would be:

(1) Implicit conversions with supression of compiler warnings.
(2) Casting from void* to another pointer type.
(3) Casting from Base pointers and references to Derived.


> const_cast
>
> This is rarely necessary.


const_cast can be handly for avoiding code duplication. You might have seen
my recent post which contained the macro NON_CONST_IN_TERMS_OF.


> reinterpret_cast
>
> This cast is used to cast between totally unrelated types. For
> instance, you may have a C function that accepts char* as input and you
> want to pass in an array of integers instead (often seen in binary file
> output). This would be done as follows:
>
> void cf(const char * input, size_t size);
>
> ... int x[] = {5, 11, 23 }; cf(reinterpret_cast<char*>(x), sizeof(int)
> * 3);
>
> Notice that a const cast is not necessary because you can always add
> const without a cast.
>
> The above code formally results in undefined behavior but is necessary
> when dealing with C code that doesn't have the strong typing and
> templates available in C++.


The behaviour is well-defined, as any address can be realiably stored in a
char* (because objects are nothing more than a finite sequence of bytes in
memory). Even before the advent of C++, proficient programmers had been
doing the following for decades:

unsigned arr[64];

char *p = (char*)arr;

There is a common misconception that reinterpret_cast is nothing but a
cowboy and a wild animal. There a several legitimate and well-defined uses
for reinterpret_cast.


> You can always perform a cast from one type to another and back
> (assuming that the size of the destination type is large enough to hold
> the entire value of the source) and this will result in defined
> behavior.


This only applies for "pointer type" to "integer type". I wouldn't try
store a pointer value in a double, regardless of how many bits a double
has...

--

Frederick Gotham

brekehan:

> I've always been a little sketchy on the differences between static,
> dynamic, and reinterpret casting. I am looking to clean up the
> following block by using C++ casting instead of the C style casting.
> from what I am reading, I should use reinterpret cast in this
> situation, is that correct? Why does static and dynamic casting fail
> me?


If you want to replace all "(Type)" casts with the "xxxx_cast" family, then
the following is a quick reliable method which doesn't require any
intelligence. (Before I begin, I'll assume that the code you're dealing
with has no need for dynamic_cast.)

Replace all casts with "static_cast", then re-compile. If you don't get any
errors, then you're good to go. If you _do_ get errors though, go through
the error lines and replace the offending static_cast's with const_cast.
Re-compile again. If you get errors for the const_cast's, then replace the
offending const_cast's with reinterpret_cast. If you still get errors for
the reinterpret_cast's, then you'll need a combination of reinterpret_cast
and const_cast.

The following is an example where a "(Type)" style cast would need to turn
into two casts:

int const arr[4] = {0,1,2,3};

char *p = (char*)arr;

would become:

char *p = reinterpret_cast<char*>( const_cast<int(&)[4]>(arr) );

or, the more convenient method which doesn't need to know the type of
"arr":

char *p = const_cast<char*>(
reinterpret_cast<char const volatile*>(arr) );

Lately, I've been intentionally paranoid about new features being added to
the language which could possibly break code like this, so I think it might
be wise to replace "char const volatile" with something like:

typedef char const volatile most_strict_char;

That way, if a new modifier like "cache" is added to the language, we just
need to add it to the typedef:

typedef char const volatile cache most_strict_char;

Then again, we could always make a function out of it, or even a macro:

#define MOST_STRICT_TYPE(type) type const volatile

--

Frederick Gotham

Frederick Gotham:

> #define MOST_STRICT_TYPE(type) type const volatile

Or the handier solution:

template<class T>
struct MostStrictType {
typedef T const volatile Type;
};

--

Frederick Gotham