is my use of typecast correct?
Author
is my use of typecast correct?
when there are 2 values like int and long, sometimes size_t and ssize_t i use static_cast (while using std::min/max). i'm careful when doing this with sign and unsign. Sometimes i recieve a pixel one API specificies as byte* and need to use it with an API that specifies char*. (What should i use? i been using char)
reinterpret_cast i know is asking for trouble, i had to use in a very specific situations (like sockets). The code runs fine, i am extra careful with this keyword. Does this do anything during runtime? is this act exactly like a c-styled?
reinterpret_cast i actually never had to use. I avoid casting when i can. When should i use this over static_cast? i rarely use static_cast so maybe i dont need this?
const_cast i never used. I plan to avoid this more then reinterpret_cast.
Quote:Original post by AcidZombie24
reinterpret_cast i actually never had to use. I avoid casting when i can. When should i use this over static_cast? i rarely use static_cast so maybe i dont need this?
const_cast i never used. I plan to avoid this more then reinterpret_cast.
I think you've got the basic idea. Avoid casts (all of them) when possible.
And a C-style cast does a bit of everything. The following
int i;short s = (short) i;performs a static_cast. But this
int i;short* s = (short*) &iis a reinterpret_cast.
That's one of the main problems with a C casts. You can't be sure which cast it uses. It tries them all in a predefined order, until it finds one that is legal.
About reinterpret_cast, all it does (practically speaking) is to reinterpret one pointer type as another. You give it a pointer to an int (4 bytes), and cast it to a pointer to a short (2 bytes), and it'll just read the first two bytes when you dereference it. Or do it the other way around, and it'll read past the end of the short, and you'll probably be screwed.
The thing to remember is that static_cast performs some kind of conversion (if you cast the int 1 to a float, you get the floating point value 1.0f, which has a completely different bit pattern. The compiler goes in and actually converts your value so you get something meaningful out)
reinterpret_cast does no conversion. It just reads the same bits, and interpret them as a different type.
That's what typically happens in the real world.
According to the standard, there's an important catch. The value you get out of a reinterpret_cast is undefined. You can't be sure that you get a pointer pointing to the same address. The only guarantee you get is that if you take whatever value it produces, and reinterpret_cast it back to the original type, you get the original pointer back. So technically speaking, a reinterpret_cast is legal to use if you need to temporarily store a pointer as another type. (perhaps you need to pass a void* to some external function, which, at a later point, passes the same void* to a callback function. Then you know that it was originally a foo*, so reinterpret_cast<foo*> is legal. But that's about all you can safely use it for.
I wouldn't say there's some kind of priority in which casts you should avoid "most" though. If you can avoid a cast, don't use it. If you have to use it, just make sure you're using the one that's legal in that situation.
A byte is probably just a: typedef char byte;
Realistically unless both API specify that the binary format of their bytes and chars are the same then no amount of casting alone will allow you to safely convert one to the other. Since such an operation presents a certain amount of risk then I would make that explicitly clear and use reinterpret_cast.
Realistically unless both API specify that the binary format of their bytes and chars are the same then no amount of casting alone will allow you to safely convert one to the other. Since such an operation presents a certain amount of risk then I would make that explicitly clear and use reinterpret_cast.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
