Hi, there is any drawback in choose C++ and an object oriented model (classes) to implement a simulation in OpenGL (or DirectX)? It's preferred to use C and a procedural programming paradigm ?
+6
A:
Not really, unless you have an unreasonably stupid design or are on a seriously limited platform there is no performance advantage of c over c++.
Martin Beckett
2010-02-10 23:39:00
+3
A:
Unless you're developing for a platform that's seriously short of memory, C++ is usually a better choice (especially in its standard library, it does use more memory, but usually does so to improve speed).
Jerry Coffin
2010-02-10 23:50:13
+4
A:
The most common drawback of object oriented programming in the context of high performance graphics (games etc.) is the memory bottleneck. OOP often (but not necessarily) leads to writing functions that operate on single elements and leveraging the standard library to generalize these to arrays. It might be preferable to operate on arrays in the first place, for example cull against all six frustum planes instead of calling the single plane culling routine six times.
Check out the following resources for more details:
- Pitfalls of OOP
- The Latency Elephant
- Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)
- Memory Optimization
- C++ Programming is Bullshit
Note that using C++ does not imply strict object oriented programming, you can use it for many paradigms. So if you code your engine in C++, you can still leverage all existing OOP style libraries such as Qt, while using any paradigm you like for the core. Although all of this is also possible in C, C++ might be a bit more comfortable.
Malte Clasen
2010-02-11 00:08:28
Yar beat me to it, good collection of links there.
Justicle
2010-02-11 00:12:39
IMHO, the 'C++ Programming is Bullshit' article is itself "bullshit". The majority of problems he points out can be avoided by just telling the compiler to be aggressive in its inlining and the rest of it are mistakes that can be made in virtually any language (apart from the use of 'virtual', though that may not be such a big problem, depends on where it is used). Its mostly just how you think about your code and whether you are aware of problems such as cache misses.
Grant Peters
2010-02-11 01:33:38
@Grant: actually, at least in this context, it goes well beyond that. Modulo trivial changes in syntax (e.g. passing a pointer instead of a reference) essentially everything he talks about applies just as much to C as to C++.
Jerry Coffin
2010-02-11 03:47:27
@Jerry: Thats my point, he's saying that this is due to the c++ language where it is actually applicable to almost any language (apart from things like APL where the language is specifically designed to work around those problems, though I'm sure you could still write a cache thrashing program if you tried)
Grant Peters
2010-02-11 07:57:26
Note that the original poster explicitly asks about "C++ and an object oriented model", and this article is about the latter implemented unwarily in the first. I guess the title is intentionally offensive, but in the slides themselves it's clear that it's about design and not about the language.
Malte Clasen
2010-02-11 15:02:32
A:
OO is particularly unsuited to high performance graphics. http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
However, if you are just learning (and not developing a commercial console game), OO is useful to build and conceptualize the engine. The usual trade offs between C and C++ programming still apply, OpenGL really doesn't come into it.
Justicle
2010-02-11 00:11:23
c++ doesn't mean that you use have to use OO and it can still be useful higher up within an engine anyway (where you will be manipulating single objects at a time). At the low level, you should try to place things into arrays and use functions designed with arrays in mind to iterate over them efficiently, high level game logic though will probably work better with an OO design (maybe not faster, but easier to code, understand and to pick up for a new coder).
Grant Peters
2010-02-11 01:41:06
Agreed, although there is a tendency for unnecessary OO symptoms to leak through the code. However as with everything, its the skill of the programmer that matters most.
Justicle
2010-02-11 03:07:36
+1
A:
It depends. How many objects are you rendering? 100s? 1000s? 1,000,000s? What platform? What level of performance do you require?
Assuming that you're looking at the low end of the spectrum for object numbers and you're more proficient in C++, then I would go with that. Keep it simple - just make it work. If you need to optimise it later then do it when you know where your bottlenecks are.
If you are looking at a large number of objects that need to be rendered then I'd be ensuring that I was using contiguous, homogeneous arrays of data to minimise cache thrashing (Both Justicle and Malte Clasen gave some good links that you should read (especially the first 2 :). You can still provide an OO interface if you like, but ensure that the engine focuses on rendering via iterating through your flat arrays.
I'd be very wary of using a naive scenetree implementation if you want performance - these, while easy to understand, are often painful to optimise without completely rewriting.
So, to answer your question, there is no drawback in using C++ over C but there is a potential performance issue in using object oriented methodologies if used naively.
Tony Albrecht
2010-02-11 03:40:42
A:
I don't think so. You can still use the (procedural) opengl interface easily from C++. That's what most programs I've seen do.
MarkR
2010-02-11 05:33:19