Sign in to follow this  

C++ Type-casting, but not really

This topic is 2848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok maybe not the best title to describe this issue (and it is actually a trivial one) so here it goes: After reading somewhere on a the programmer portfolio review thread here on Gamedev.net some people mentioned that using lines of code like, float f; int i = (int)f; is not very C++ like but more C like and that they should use int i = int(f); int i = static_cast<int>(f); So what do you think and what version do you use? [Edited by - projectghost on February 26, 2010 12:33:40 PM]

Share this post


Link to post
Share on other sites
I don't use the C++ versions (except the const_cast) because:
-static casts are too long to write;
-I don't use reinterpret_casts, dynamic casts and RTTI.
-const_cast is an exception because it may point to possible bugs whenever I decide to work with things like that.
I'm not really a professional now but I'm developing a practical coding style for myself.

Share this post


Link to post
Share on other sites
Quote:
Original post by snake5
-static casts are too long to write;


IMHO, that is not a good argument. Plus using static_cast allows me to search or search and replace far easier then C style cast. And that itself it's worth its weight in gold.

Share this post


Link to post
Share on other sites
Quote:
Original post by snake5
There's no right and there's no worst. They use what works best for them.
Right and wrong doesn't exclude the possibility of a reasonable middle ground.

On a less philosophical note, the presence of casts (particularly dynamic_cast) in your code generally indicates that you screwed up the design phase. The exception is when you have to interface with a legacy APIs, which are often not const-correct, etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by DoctorGlow
Quote:
Original post by snake5
-static casts are too long to write;


IMHO, that is not a good argument. Plus using static_cast allows me to search or search and replace far easier then C style cast. And that itself it's worth its weight in gold.


Exactly my thoughts. If static casts are too long to write, maybe C++ programming is not for you? Because there are a lot of stuff in C++ that is too long to write, maybe don't write at all - like with static casts.

Quote:
Original post by snake5
-I don't use reinterpret_casts, dynamic casts and RTTI.

I'm pretty sure you use reinterpret casts, but you doing them with C syntax.


Share this post


Link to post
Share on other sites
Quote:
Original post by snake5
Quote:
Quote:
I was more wondering what was actually used in professional application/games
The worst one ;P
There's no right and there's no worst. They use what works best for them.
Sorry, was just joking that real-world "professional" code is often very ugly ;P

Share this post


Link to post
Share on other sites
Personally, when dealing with primitive types like int and double, I always use the C-style cast.

When dealing with virtual classes, I use dynamic_cast.

When casting non-primitive objects and when dynamic_cast isn't suited for the situation, I use static_cast.

When doing something obscure with classes or primitive types, I sometimes use reinterpret_cast.

When, also for something obscure, needing to cast away const-ness, I use const_cast (and not the simple C-style cast).

But I almost never use static_cast for primitive types like double to int, simply because I know what the C-style cast does and means, it does exactly what it should do, and the notation looks cleaner.

Quote:
Original post by bubu LVExactly my thoughts. If static casts are too long to write, maybe C++ programming is not for you? Because there are a lot of stuff in C++ that is too long to write, maybe don't write at all - like with static casts.


Hmm, C++ is quite ok in that aspect imho, Java requires much more writing than C++ for example. Even C requires much more if you do things like text manipulation or working with dynamic arrays.

[Edited by - Lode on February 27, 2010 5:59:18 AM]

Share this post


Link to post
Share on other sites
I like the fact they are longer to type. Makes them easier to spot. And when there starts to be alot of casts around, I'd say the program needs design attention.

I use always static_cast with primitives, but I dont see them much around anyway. From double to int ill just call round_down<int>(), and other more expressive functions.

dynamic_cast is no-brainer, but also sign of design problems. With mix-ins static_cast does the job.

reinterpret_cast is a nice ugly name for a ugly cast, where stuff can go wrong.

const_cast is a evil way to promise user ill wont change your parameter, and change it anyway. mutable is better becouse at least you'll see it in header that stuff can change.

I also use boost::numeric_cast where I want to be sure I wont overflow.
And for shared_ptr I have this fast_pointer_cast, which asserts dynamic_cast == static_cast in debug, and is only static_cast in release. And checked_pointer_cast which throws std::bad_cast if dynamic_cast failed.

Anyway.. I really don't like casts, and C cast for the least.

Share this post


Link to post
Share on other sites
I tend to use the constructor style casting for primitives:


int i=10;
float f=float(i);


since it dovetails nicely in with using the equivalent explicit constructor syntax with user-defined classes.

I tend to only use static_cast<> for downcasting when I know for sure the instance can be casted correctly, but as swiftcoder noted above, this or dynamic_cast<> always makes me suspicious that my design is flawed.

I always use reinterpret_cast<> when converting a pointer from one type to another by just copying bits as this is exactly the kind of operation that should stand out like a sore thumb in code. The only exception I have to this is when I'm working with the Windows API. I tend to do:


HBITMAP OldBmp=(HBITMAP)SelectObject(Dc,Bmp);


This is so idiomatic in Windows API code that it is easier for me to understand than:


HBITMAP OldBmp=reinterpret_cast<HBITMAP>(SelectObject(Dc,Bmp));


but purely due to the sheer number of years that Windows API code has been written like that.

Other than that, I avoid C style casts.

Share this post


Link to post
Share on other sites
Quote:
Original post by Aardvajk

HBITMAP OldBmp=(HBITMAP)SelectObject(Dc,Bmp);


This is so idiomatic in Windows API code that it is easier for me to understand than:


HBITMAP OldBmp=reinterpret_cast<HBITMAP>(SelectObject(Dc,Bmp));




#include <windowsx.h>
...
HBITMAP OldBmp=SelectBitmap(Dc, Bmp);

Share this post


Link to post
Share on other sites
I always use the C++ style. The fact that they take longer to type stand out more in the code is a good thing, IMO. Any time you cast from one type to another, it should be very clear that it is occuring and why it is occuring. C style casts or implicit casts are easier to miss when reviewing code.

Share this post


Link to post
Share on other sites
I haven't been a profession C++ programmer for 5 years (doing C# stuff primarily now), but I was for 5 years ... and I am fairly sure that in our code base at the start of my career it was ALL C-style casts ... but by the end of my career we had adopted the newer casts for many cases.

We always used dyamic_cast for dynamic casting (downcasting), const_cast for const casting (doing nothing but removing const for interfacing with non-const correct APIs) and reinterpret_cast for reinterpret_cast (the case of code that would always be a bug if the program doesn't know for sure what the REAL type is).

The only one I don't remember being used by everyone was static_cast. I think the most common choice for true conversion was the constructor call version ... although that one took a while to get used to - and none of us every loved any of the 3 choices (the c-style was frowned upon only because it was so powerful that it made it easy to miss bugs - but it was still used sometimes).

Share this post


Link to post
Share on other sites

This topic is 2848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this