-
January 29th, 2004, 07:34 AM
#1
a deffirence between "C" like type conversion and VC++ cast operators
Is there any difference between "C" like conversion and VC++ cast conversion operators (reinterpret_cast, dynamic_cast, static_cast).
I mean not a logical difference, I mean low-level code generation differences.
Maybe cast conversion operators are used just in help for programmers???
-
January 29th, 2004, 07:55 AM
#2
There is a big difference:
C style cast will just do it, assume that the casted object or variable is of a type in which it is casted.
If not, you programm can heavily crash.
C++ style includes additional information to each variable or object (you have to enable it in project options). It tests if the cast is possible. If not, it returns NULL. You can test result against NULL and assert.
With C++ style, your program is safer, but less efficient.
-
January 29th, 2004, 08:32 AM
#3
Is that mean that if the programmer watches for correctness of types conversions, then the program, which was written using "C" conversion style, can be more effieciently, than one, which was written using cast operators?
-
January 29th, 2004, 09:05 AM
#4
Originally posted by reptile
...the program, which was written using "C" conversion style, can be more effieciently, than one, which was written using cast operators?
Yes, that is the meaning.
If you use cast operators like dynamic_cast<>, then the compiler will test for you if the cast is correct but you will pay for this in reducing a performace.
On the other side, if you use C-style, and cast something wrong, that will be accepted from compiler, but you will have a garbage pointer at runtime. Your program is more efficent, but you have to take care that your pointers are valid, you can't test pointers against NULL.
-
January 29th, 2004, 09:19 AM
#5
It might depend on programming stylle also.
If a reinterpret_cast returns NULL it means that there is some problem with your code. It will not crash but some functionality will not be available ( most likely you will leave the current execution block).
If you want to handle each cast this way, the chekings will propagate through your code and you'll have to insert a lot of otherwise unnecessary ifs. I'm not against defensive programming but I think there are better options ( programming by contract etc).
Of course you might want to use this to check some pointer's type. But that can also indicate some poor design/implementation.
In my opinion, reinterpret_cast should be used in DEBUG versions, followed by assertions.
Code:
#ifdef _DEBUG
#define cast( expr, type) reinterpret_cast<type>( expr)
#else
#define cast( expr, type) (type*) expr
#endif
Har Har
-
January 29th, 2004, 09:21 AM
#6
I expect to see a lot of strong words, arguments and refferences to my post above.
Har Har
-
January 29th, 2004, 09:42 AM
#7
Originally posted by PadexArt
It might depend on programming stylle also.
Code:
#ifdef _DEBUG
#define cast( expr, type) reinterpret_cast<type>( expr)
#else
#define cast( expr, type) (type*) expr
#endif
Cool.
I like it. I already thought about replacing C++ style casts manualy, once the program is tested.
I don't like to insert #ifdef _DEBUG somewhere in code, it makes code less readable, but, your way, it's only defined once as a macro.
Simple and strong.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|