static_cast and (normal)cast

This is a discussion on static_cast and (normal)cast within the C++ Programming forums, part of the General Programming Boards category; why should one use static_cast<type>var instead of (type)var? from what i read on MSDN, both types of casting are the ...

  1. #1
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401

    static_cast and (normal)cast

    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.
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  2. #2
    Skunkmeister Stoned_Coder's Avatar
    Join Date
    Aug 2001
    Posts
    2,572
    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.
    Free the weed!! Class B to class C is not good enough!!
    And the FAQ is here :- http://faq.cprogramming.com/cgi-bin/smartfaq.cgi

  3. #3
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    ok, so what is the difference between those 4 casts?
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  4. #4
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    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.
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  5. #5
    Skunkmeister Stoned_Coder's Avatar
    Join Date
    Aug 2001
    Posts
    2,572
    Free the weed!! Class B to class C is not good enough!!
    And the FAQ is here :- http://faq.cprogramming.com/cgi-bin/smartfaq.cgi

  6. #6
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    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?
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  7. #7
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,786
    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.
    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 mistakes

    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;
    }

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21