What, if any, is the difference? So far the only thing a reinterpret_cast seems to add over a C-style cast is just more clutter to my code...
What, if any, is the difference? So far the only thing a reinterpret_cast seems to add over a C-style cast is just more clutter to my code...
reinterpret_cast doesn't work in all the same situations as a C style cast, so by simply looking at it you have a better idea of what is happening in the code. (Which means less "clutter" for the reader.)
Do you not know the differences in where they work or are you just not sure why it matters.
BTW, reinterpret_cast should be pretty rare in your code. Where are you using it?
I understand the usefulness of the other casts; they make mention here:
http://www.cplusplus.com/doc/tutorial/typecasting.html
that reinterpret cast really has no limits (only being confined to pointer-types), and can be used to construct any valid but meaningless (and dangerous) cast... sounds like good 'ol C-casts to me
My interest in this is for ifstream::read(), which takes a char* (I'm used to the handy void* of fread()) and so have to cast all arguments (most of which are exact-width types, i.e. XintN_t) to char*. If I use reinterpret_cast, it's a bit of an eye-sore, so I'd rather just use C-style cast.
Though, in the time it took me to write this, I've come up with a handy (but not fool-proof) shortcut:That way I can do it the "C++ way" and still keep my code relatively clean.Code:#define read( s, n ) read( reinterpret_cast<char*>( s ), n )
One difference that comes to mind is that a C-style cast can be used to cast away const-ness, but reinterpret_cast cannot (const_cast would have to be used).Originally Posted by @nthony
That's part of the intention, other than making it easier to find the casts used in a program.Originally Posted by @nthony
Except that macros is not the C++ way.Originally Posted by @nthony
Last edited by laserlight; 11-19-2008 at 12:14 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
>> reinterpret cast really has no limits (only being confined to pointer-types)
That's a very important limit. If you find a reinterpret_cast in the code it implies that the author either copied it from somewhere, or is aware of C++ casts in general and is therefore aware that he or she is using the dangerous cast. A simple C style cast does not indicate whether or not the author was intending to do a simple cast and made a mistake, or if the author intended to a "dangerous" cast.
I personally think the reinterpret_cast looks good there, as it makes it obvious that we're working with raw data. However, most people are familiar enough with read() that I don't think using a C-style cast there would be that bad if it bothers you that much. You can also make a function that does the cast for you but has a name that is more appealing to you. This idea has problems, including the fact that readers of your code are more likely to know what the reinterpret_cast means than what your function means. But it's better than the macro.
The other thing the C++ casts are good for are if you wanted to do a code review and look for all code that uses a cast to make sure someone didn't screw up when casting. How would you do that with a C cast?
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
Personaly I would just prefer if the had a shorter name. Why type reinterpret_cast when the it could be rcast. The standard/default things can have a short name, because everybody knows them. All C++ programmers would understand cc<int*>(ptr) the same as const_cast<int*>(ptr), why have the big name? It is simply 9 keys + 3 shift-keys more than a C style cast. That is too much for my point of view. And for something that people would definately use over and over again
The point is to discourage the use of casts. Read Stroustrup's answer to the FAQ: What good is static_cast?Originally Posted by C_ntua
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
I really don't think long names discourage casts. If anything, it just makes programmers use c-style casts. And what's more is that when you really DO need to use casts, they are long and tedious to spell out. Again, makes (at least me) revert to C-style casts.
If you're using enough casts that you actually complain about the length, then you're using them way too much. This is C++, not Java (where you need to use a cast on just about every 2nd line).
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
Yes, it probably has that unfortunate side effect since C-style casts still exist. I suppose the next best thing is to forbid them for new code in the relevant coding standard, and maybe have the static analysis tool (if any) detect them.Originally Posted by Elysia
I see that as a Good Thing. It makes you take more time to decide if you really need the cast, and if so, if it is the right cast to use.Originally Posted by Elysia
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Yeah, so you can have safe casts as you do. So you have to choose what you want. That is OK. But having long names is an overkill. What if you want to cast something returned from a generic function? You will need to right a long-unreadable line. Like:
Now, look at this:Code:myType a = reinterpet_cas<myType>(myFunction<thatType>(int one, int two));
Much cleaner. Also this:Code:myType a = (myType) myFunction<thatType>(int one, int two);
Code:myType a = reinterpet_cast<myType(b);Again you wouldn't want to read a big line for the more useful information which is myType a = bCode:myType a = (myType)b;
Personally I like keywords/operators for these things. Dunno, like:
Generally, you want the more useful information to be first. You want to different things to be seperated. You don't want one complex line with a lot of symbols. That is just how I see things.Code:myType a = b cast interpert(myType); myType a = myFunction<thatType>(int one, int two) cast interpert(myType);
Incidentally, concerning your suggestions of renaming reinterpret_cast to rcast and const_cast to cc: if you read the article that I linked to, you will find that "a further reason was for the new-style casts to match the template notation, so that programmers can write their own casts, especially run-time checked casts". In fact, you could write say:Originally Posted by C_ntua
Code:template<typename DT, typename ST> inline DT rcast(ST x) { return reinterpret_cast<DT>(x); } template<typename DT, typename ST> inline DT cc(ST x) { return const_cast<DT>(x); }The cast is useful information.Originally Posted by C_ntua
Actually, const_cast, dynamic_cast, reinterpret_cast and static_cast are keywords (as in reserved words).Originally Posted by C_ntua
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)