why should one use static_cast<type>var instead of (type)var?
from what i read on MSDN, both types of casting are the same.
Printable View
why should one use static_cast<type>var instead of (type)var?
from what i read on MSDN, both types of casting are the same.
no they are not totally equivalent.
the old c style cast (type) is replaced in c with three separate casting operators...
static_cast<type>()
reinterpret_cast<type>()
const_cast<type>()
There is a fourth. dynamic_cast<type>() but this is not equivalent to any c style cast.
If just for more readable,self documenting code use the c++ style of casting unless you are programming in straight c.
ok, so what is the difference between those 4 casts?
i just read some more on MSDN, and now i reckon that it would be pointless to bother with all those fancy casts. C-Style casts have always worked fine for me. If i make a mistake with a cast, i find it and correct it. why should a runtime check be necessary? if the program doesn't work, then the programmer will fix the problem before he/she releases it.
that certainly was interesting reading, but its too late and i dont know enough about virtual functions or derivation to follow it. i think perhaps that at my stage of programming i have no need of these C++ casts. i mean, when i cast, i'm usually casting from some vartype to WPARAM or LPARAM, or from (int *) to (void *) etc. in those cases using C++ casts would not be worth the bother. am i right about that?
The problem is that with a cast, you are telling the compiler that you know what you are doing......with a simple c cast, you can totally change how that pointer or variable is used...and if you arent carefull you can easilly make mistakesQuote:
Originally posted by bennyandthejets
i just read some more on MSDN, and now i reckon that it would be pointless to bother with all those fancy casts. C-Style casts have always worked fine for me. If i make a mistake with a cast, i find it and correct it. why should a runtime check be necessary? if the program doesn't work, then the programmer will fix the problem before he/she releases it.
I prefer the new casts because it helps me realise what I am trying to do...for a simple cast between primatives...static_cast works, but will choke if I inadvertantly try to do something else (loose const......cast between 2 incompatible pointer types)...this is a good little safety net on occasions as sloppy casting can cause problems
const_cast isnt something I find myself using much and if I do I know I have to be sure that the memory isnt const...only my access to it
reinterpret_cast is for when you are doing something out of the ordinary (like casting a primitive to a pointer or vica versa - this might seem like a design flaw, but if you ever get into Win32 coding, you will see lot of occasions to do stuff like this). Again when I use this, it forces me to think of the implications of what I'm doing.....
Code:#include <iostream>
struct foobar{
void Sing()const{std::cout << "x = " << x << std::endl;}
int x;
};
void f(const foobar& foo){
foobar& reffoo = const_cast<foobar&>(foo);
reffoo.x = 55;//safe....but not desirable
foo.Sing();
}
int main( void ){
foobar foo;
foo.x = 10;
//cast 2 different variable of same size....(on win32)
long lPtrfoo = reinterpret_cast<long>(&foo);
std::cout << "foo memory start as long = " << lPtrfoo <<std::endl;
f(foo);
//normal cast between 2 primative types
char c = static_cast<char>(foo.x);
std::cout << "foo.x as char = " << c << std::endl;
return 0;
}