|
|
|
This thread is locked; no one can reply to it.
|
| reinterpret_cast speed |
|
Options
Member #3,513
May 2003
|
Like the title says reinterpret_cast speed;) compared to type casting is there any diffrent run-time ? |
|
Korval
Member #1,538
September 2001
 |
No. |
|
gillius
Member #119
April 2000
|
reinterpret_cast should only work on pointers from what I understand, I've never tried it on data variables, but if it did work, I can rarely see a use from that, but in that case, reintepret_cast would be different from type cast, for example casting a float to an int. If you used reinterpret_cast, there would be no conversion made. It would be the same as *((float*)&intVar) to do a reinterpret cast from int to float. I've never tried it though, I wonder if it works. Gillius |
|
Hein Zelle
Member #217
April 2000
|
It should, I always thought that's what it was made for. (to read the bits of type 1 as if they were a type 2) How do you use it with pointers, what's the use for it? So far I've only had to use static_cast (replace of normal cast), dynamic cast (virtual inheritence) and const_cast. |
|
A J
Member #3,025
December 2002
 |
use of const_cast is a bad idea.. it highlights bad design. ___________________________ |
|
Bruce Perry
Member #270
April 2000
|
Quote: How do you use it with pointers, what's the use for it? Not that I know C++, but I'm guessing this is a great way to reduce the portability of your program for absolutely no reason whatsoever. Pointers to different types aren't guaranteed to have the same representation under ANSI C (though they may be for C++ ...). A J: can you clarify? By the way, don't reinterpret a float as an int or vice versa unless you really have a good reason to do so. Processors apparently have a write queue for floats, and another for ints; if you try to read something that's in the wrong write queue for the format you're reading, then the processor will get delayed a lot. Bob can give you a more precise/specific argument here, since he's the one who told me about this. -- |
|
A J
Member #3,025
December 2002
|
if you use const_cast to remove the const of an object, then it should not have been a const to start with. const is const for a reason. also, a compiler will have optimized that variable with const-ness in mind, and suddenly you un-const it.. then its going to not only just un-const it, but my have created a bigger problem. ___________________________ |
|
Bruce Perry
Member #270
April 2000
|
Ah, understood. Well, const_casts may be useful if you are using C libraries. For instance, Allegro's GUI requires you to build arrays of DIALOG structs, and the struct contains three(?) generic data pointers: void *dp, *dp2, *dp3; In many cases, these are set to point to strings. If you want to compile with -Wwrite-strings, you will need a const_cast. In other cases, these are set to point to integers that Allegro's GUI should change when the user changes an option in the dialogue. So they can't just be made into const pointers. So that's why const_cast exists. If you have a philosophy that the use of a feature signifies bad design, then you should ask yourself (or ask us) why it exists. Such features were probably put in for a reason, after all. -- |
|
|
