5 replies to this topic

[Max707]

Hello, I have been learning C++ for the past few months now and focusing on or towards game development. I have a few questions that i tried searching answers for, with no actual good results. I was like it if i could get your opinions on the questions below.

1. It seems as if with C++, the solution to ever problem is OOP, but what are some situations where you should not use OOP.

2. What other paradigms that are used commonly in game development. I have been reading up on Data-Oriented Design/Programming the past week(DOD), so are there any others?

3. Is C still used commonly in game development on platforms such as PC and major gaming consoles or is it used more on protable/embedded devies such as the DS/PSP/Vita/etc. Or is it a mix of C and C++ depending on what you are currently programming such as UI, the core, etc.

4. Realted to question 3, is C still used quite a bit in game development

5. Are many features of C++ used commonly or do most companies put strict rules on what features to use and what features not to use.



Those are my questions for now. If i think of any that i missed i will edit the post. Thanks.

Edited by Max707, 01 July 2012 - 04:42 PM.

[ApochPiQ]

1. The solution to a problem should only be OOP if the problem calls for OO solutions. Don't fall into the trap of sledge-hammering everything with objects. A classic example is logging: debug logging is generally best left to free functions rather than objects, for example. Some of this will vary with individual tastes, and you will find people rabidly arguing for one way or another, but in general your best bet is to just do the simplest thing that you think will work. As you gain experience and work on ever-larger code bases, you will discover for yourself a good set of instinctive rules for when to use what kind of solution. Always be mindful of that itch in the back of your brain that says "there has to be a better way" - it's usually right.

2. "Paradigms" are as numerous as political opinions and just as difficult to discuss in civilized company without devolving into heated screaming matches. I'm a big advocate of the "just get shit done" paradigm. Think about how to build your code in a way that solves the problem at hand - again, don't fall into the trap of smacking everything within reach with a single hammer just because that's the only tool you know. Worrying too much about whether or not you're conforming to a "paradigm" is wasted time.

3. Most shops have gone to C++ these days. There are still places where C is king, but they are dwindling. Mixing the two is generally a sign of bad technical leadership.

4. See answer to #3.

5. There are often limitations imposed - either by the tools being used, or artificially by the team leadership. For instance, heavy use of template metaprogramming is often forbidden, either because the platform's compilers can't cope with it, or (more commonly) because most programmers have better things to do than wade through a bunch of template errors every time they spell something wrong.

[joew]

I don't have much to add as Apoch pretty much nailed the answers. I do believe there is one time that a C/C++ mixed codebase is acceptable which is when moving from a C codebase to C++ over time in production... although that is why he stated "generally"

Regarding #5 the standard library is often outlawed as well with the reasons being memory allocation (nobody likes shoehorning with the STL allocators), people not paying attention to what is happening internally, and wading through template errors. I don't think anyone mentions performance anymore these days, other than programmers not thinking about the properly and/or not using the containers properly. With C++11 having move constructors / assignment it just makes the containers perform even better in many cases. So in reality if you look at the main reasons the STL is normally outlawed it is strictly due to end-user error and not the library itself.

[Matt-D]

"C++ is a multi-paradigm programming language that supports Object-Oriented and other useful styles of programming. If what you are looking for is something that forces you to do things in exactly one way, C++ isn't it. There is no one right way to write every program - and even if there were there would be no way of forcing programmers to use it."

See also:
http://www2.research.att.com/~bs/bs_faq.html#multiparadigm
http://www2.research.att.com/~bs/bs_faq.html#Object-Oriented-language
http://www2.research.att.com/~bs/bs_faq.html#generic
http://www2.research.att.com/~bs/bs_faq.html#oop

[Max707]

Thank you to everyone who answered. If helped me out alot and as like Apoch said, whenever you try to research these topics it is just a heated argument with no backbone for either side. Just screaming into a massive void. Thanks again and re-enforcing the fact to always follow you curiosity/itch if something does not seem right and that there has to be a better way to solve this problem.

Edited by Max707, 01 July 2012 - 08:47 PM.

[ferrellwa]

Regarding question 5:

During my studies at my previous university, our professor loosely enforced Google's C++ style guide. It could prove to be pretty helpful if you're ever unsure about some C++ usages. Although I'm definitely a newbie, I always keep this in my browser as a reference!

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml