OK. Grab your religious robes and prepare to preach... I''m currently doing a s/w eng. degree, and thus OO programming practices have been strongly embedded in my psyche. However, not content with supplying a consistent education with my other lecturers, One lecturer claims OO can be BAD!!! I''ll set the scene in hope someone can straighten out my now damaged life - The lecturer is for a class on Graphics - More theory than API stuff, so we spend most of the class wrapping the win32 api to be a little easier and logical to work with. In implementing this library (as a basic example) the functions and variables are defined as globally accessible externs (for example DrawLine(Point,Point), which you can set LineStyle, LineThickness, and LineColour. Now for the last 2 1/2 years if we had have done anything BUT put this in class we would have failed (or not, they arent that extreme, but its only a matter of time ) So I put it to you, when working in graphics what is a better (not best - it don''t exist) practice? Use Classes and thus extra time for construction/function calling - Use Globals, have the speed (and risk)of immediately accessible variables - Use static variables to functions, or other soloutions.... Thanks for your help, but please, leave no blood on the carpet

And that I understand entirely. I was more hoping to get the gamedev communitys perspective on which is useful where, and when NOT to use an approach.

OOP is not end-all be-all of solutions. Some things are just easier/faster to implement using a procedural approach. That''s why in C++, you can use either.

I'm not sure I have enough experience to make a well informed decision about this (I have been programming in C++ for over 2 years during my spare time), but I'll state my opinion.

Times when OOP is good:
*you have lots of people working on the same project at once
*the project is large
*globals can be bad when you are writing multithreaded code

Times when OOP doesn't matter:
*Less than say 5 people are working with the source code
*The project is small

Times when OOP might be a problem:
*globals can sometimes be faster, because they don't have to be reallocated on the stack each time a function is called. So a small function that uses only globals is faster than its OOP equivalent.


The effects of OOP for large projects is very well documented and has been proven over and over again, I don't think anyone can argue about this.

A lot of people like to bring up performance issues with OOP and I think it depends what people mean when they say "OOP". I get the feeling by "OOP" you mean the OOP features of C++ like classes, virtual functions, inheritance, and polymorphism. In this case, I think the performance difference simply doesn't exist - if the coder knows what is happening under the hood and understands C++ well, properly written C++ code can be just as fast as C code. If you are wasting extra time for constructor and function calls in tight inner loops, I think you need to think about redesigning your code. A lot of people don't understand what C++ and the compiler is silently doing under the hood, so using C for performance code can be a good idea sometimes.

Edit - After rereading my above paragraph, I don't really like what it says. I think Fallenangel says it best - C is a subset of C++, so use whatever is best for your given task. Performance code is easier to write in C, in C++ it is harder.


[edited by - Z01 on August 31, 2002 1:36:02 AM]

The best line to take is to forget about OO. You''re using C++, right? Then learn the different structures and mechanisms belonging to C++ and apply them as seems appropriate to the problem. Don''t worry if your design is "pure OO" or not. It''s likely that a good design will end up having a lot about it that is OO, but worrying about OO as an end in itself is not the way to approach a design problem. This also goes for other languages such as Java. Use the structures in the language to good effect, and don''t concern yourself with the "OO-ness" of it all.

Of course, this leads to the issue of learning the available structures and mechanisms, and when to use them. Now, *that''s* the real problem...

/agree Sabreman. Couldn''t have said it better...