Sign in to follow this  

C++ Feature Usage

This topic is 4110 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

I searched the forums and was unable to find information pertaining to my questions below. If you know of any threads that are relevant, any help on their location would be appreciated. I've been doing a lot of reading lately regarding the language choice of game developers. Obviously C++ is chosen in the majority of cases. Analyzing this choice a little bit further I found that most only use a subset of C++'s features. Many distance themselves from the usage of virtual functions (therefore limiting the usage of polymorphism), and use exceptions sparingly (sometimes disabling exception handling all together). I have several questions related to this usage: 1) Do these developers continue to use the STL? If they do, how? Doesn't the STL use exceptions as a means to communicate errors? What is the STL's behavior if exceptions are disabled? 2) Where memory management is concerned do most developers go so far as to redefine the default new and delete operators? Most developers make a very big point to not, at any time, allocate memory during the game loop. That all memory should be allocated prior. By putting two and two together I came to the conclusion that this doesn't mean that you can't have your own memory management routines (i.e. your own mechanism for "allocating" memory from a pre-allocated pool), but that you shouldn't allocate memory from the system (i.e. call the default new operator, malloc(), etc.). How does this impact usage of the STL? The STL can allocate like crazy if you're not paying attention. Do you create and pass in a custom allocater in all necessary places?

Share this post


Link to post
Share on other sites
Quote:
Original post by Barrel
1) Do these developers continue to use the STL? If they do, how? Doesn't the STL use exceptions as a means to communicate errors? What is the STL's behavior if exceptions are disabled?
Not much. The STL implementations on certain platforms -- non MS consoles in particular -- used to be questionable. Plus the game developer mentality of reinventing everything because it will be "faster" dominates.
Quote:
2) Where memory management is concerned do most developers go so far as to redefine the default new and delete operators?
Not necessarily, but there will be some kind of memory management system. Whether that system is routed through new/delete or handled completely separately is a different matter. Nobody likes the C allocator. It's used because it's the only cross platform way of getting memory. (And the way C/C++ are designed, a generic solution can't do any better.)

Share this post


Link to post
Share on other sites
Thanks for the quick reply Promit. That's what I kind of thought.

I did try to disable exceptions for the STL in VC++ by setting _HAS_EXCEPTIONS = 0. Then I monkeyed with the _Throw and _Raise functions. It compiled and linked, but it was...uncomfortable. I had no idea what behavior to expect. I turned exception handling back on. Anyone know the overhead associated with having exception handling turned on, but not using it?

Also, since virtual functions are frowned upon do people leave RTTI turned on? I've noticed several threads in this forum discussing the usage of typeid and dynamic_cast, but no ones said anything about not using them at all.

Share this post


Link to post
Share on other sites
Quote:
Original post by Barrel
Thanks for the quick reply Promit. That's what I kind of thought.

I did try to disable exceptions for the STL in VC++ by setting _HAS_EXCEPTIONS = 0. Then I monkeyed with the _Throw and _Raise functions. It compiled and linked, but it was...uncomfortable. I had no idea what behavior to expect. I turned exception handling back on. Anyone know the overhead associated with having exception handling turned on, but not using it?

Also, since virtual functions are frowned upon do people leave RTTI turned on? I've noticed several threads in this forum discussing the usage of typeid and dynamic_cast, but no ones said anything about not using them at all.


Unless you have profiled your code and proved that you can make a solution to issues such as polymorphism, RTTI and error handling, then you are just trying to find excuses not to use the systems that are built into the language.

The kind of people ( not me anyway ) who disable exception handling and dont use virtual functions and who can expect to see a benefit from this are people who already know all the reasons of when not to use them, and have demonstrated that their solution is better.

I use virtual functions and exceptions because I dont make games that even tax my processor. Until I do, and until I can prove that these are to blame and not some misconception on my part, I'm going to keep using them.

This, of course, may not apply to you. You may be making good games, I don't know [smile]

Share this post


Link to post
Share on other sites
RTTI increases code size a little but (but not the size of code in I-cache). There is no overhead to RTTI unless you actually use it. Once you start using typeid, things get slow(er).

Exceptions have a constant time overhead across the project. If you disable exceptions, I think you save a cycle or two on each function call. If exceptions are enabled, you lose nothing by using them or not -- exceptions are only slow after they fire. (The obvious aside being that you should use exceptions when you really mean it.)

Virtual functions are ok on most non-embedded platforms, but in some places you should use them sparingly. If you're calling a virtual function per vertex or something, well that's obviously wrong and will hurt. If you're calling a virtual function once to render each object, no big deal.

Share this post


Link to post
Share on other sites
No good games here! :)

Actually just a bunch of prototypes doing a bunch of different things. All of them making use of the previously discussed items. And that's what bothers me. I'm very comfortable using these features, the STL, etc. But then I read about development houses shying away from these features.

Basically, since I'm at the point where I've decided to invest the time and energy to make a complete game, I don't want to build an infrastructure that I'm going to eventually scrap because of performance issues. Obviously if you were to not use virtual functions your design would be drastically different then if you were to. Same goes with exception handling vs. structured error returns.

Share this post


Link to post
Share on other sites
Ah yes, profiling. There's no excuse for being lazy. I need to do some serious investigation on my own.

I guess I'm surprised at how little information is out there with regards to these topics when game developers are so adamant in their usage (or lack thereof).

Share this post


Link to post
Share on other sites
Quote:
Many distance themselves from the usage of virtual functions (therefore limiting the usage of polymorphism), and use exceptions sparingly (sometimes disabling exception handling all together).


How odd. All my systems are just chock full of RTTI and (the posibility of throwing or handling) exceptions, and I've never had performance issues.

Share this post


Link to post
Share on other sites
Quote:
Original post by Barrel
Also, since virtual functions are frowned upon do people leave RTTI turned on? I've noticed several threads in this forum discussing the usage of typeid and dynamic_cast, but no ones said anything about not using them at all.
They aren't frowned upon. What gave you that idea? They are key to polymorphism and OOP. You simply don't use them when have no need to. You only look for a (perhaps ugly) alternative if profiling tells you that it is too slow. There may not always be a better alternative either.

I don't think RTTI is used as much because it is not often needed.

Exceptions are another story. Some projects will use them a lot, others will barely touch them. Those that barely touch them most likely do so because they don't know if the rest of their code, or other peoples code they are using, is exception-safe, or they know it isn't exception-safe.
Other times it might be because many functions don't have any uncommon failure modes. Either the function has no failure modes, or they are so common that they aren't exceptional, and using exceptions would hurt performance unnecessarily.

Custom allocators need only be considered when fixing performance problems. Most often people seem to use the default allocator, afaik. Using reserve() on a vector where appropriate etc, is more important, and such optimisations should be considered first.

Share this post


Link to post
Share on other sites

This topic is 4110 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