First of, I'm sorry I'm a little late to the party... also, I'm sorry if some of my English is subpar... I'm not a native English speaker and sadly have less experience expressing myself in long sections of text than I would like.
I was first about to write “Why all the hate/distaste for OOP?”, but I think I already know where you all come from.
If you are talking about strictly OOP, then I can REALLY understand the hate, but that's not what C++ is about in my opinion. In C++, OOP it's just one tool in a large set of different tools that can be powerful if used “correctly” (just like templates… oh… my distaste for boost…). It can be very useful if applied correctly, but outmost horrible if misused, like most other things as well.
I’ll try to give you at least my view on OOP, and it’s for you to judge if you want to listen to what I say and what my merits are worth (I’ve only released one commercial game as an in-house programmer, which is Clodubuilt, where we were two programmers over the course of 3 years writing the game, the engine, editors and some other tools, while starting up and managing the company and trying out marketing… I also worked on design of the game, art, and other stuff as well).
I’m a little tried on the hate on OOP and I think it’s an overgeneralization. In my opinion, if you are wiring an engine or any code with high demand on performance you must have a deep knowledge of everything you are using, no matter what it is. But as long as you have that understanding, there is no problem. Object orientation can be useful, but you should never use it blindly without considering alternatives, just like with everything else, and make sure you know what is happening under the surface.
In our engine we use a lot of objects and hierarchies, but we also use a lot of C-style code and sections where we extend base behaviors with function pointers and void pointers and such. It all depends on where in the engine or game it is, how much we intend to build upon it, or how many people we expect to get in contact with it, and what knowledge we expect those people to have and so on.
Just as a disclaimer though, our code is FAR from perfect, just like with most projects developed under tight time constraints I would say, and we definitely have things we want to work on and make better. That being said though, for the most part, the largest decisions that we regret, have been related to third party libraries we’ve used, not how we chose to structure our code/engine. (we will most likely work to remove those libraries in the future… as soon as we can as far as I’m concerned)
We have been refactoring code, restructuring huge sections, and generally rebuilding and iterating a lot throughout the development. Now that we are more or less prepared to move on from the project, we will try to get some time to look over and restructure things some more to make sure we separate the engine, game and tool code as much as possible. Along with that we will most likely also break out some of our C style sections to become more object oriented, as it will help to make it cleaner and easier to work with in the long run for us. Most of those sections are not even part of any bottle neck either. So ease of use, extendibility and maintainability is much more important in those sections.
We have with our design managed to build an engine and game that is very data driven and flexible. I’m sure that most of it would be possible without object orientation, but it would likely be much less “safe”, and much harder to extend and continue to work on in future projects. (we will see how it goes, but we might try to keep the engine fully backward compatible to still be able to run Cloudbuilt even when the next game is done).
In order to be able to do large underlying changes without affecting other code and require too large rewrites, we need to be able to abstract many things that happen underneath. We must of course make sure to not add unreasonable overhead to the things we do, but we use a lot of object orientation to achieve this.
We have yet to port the engine to any console, so we will have to see if that changes my opinion if we get around doing that, but I don’t think it would become any issue. We know where our bottlenecks are, and it’s not due to any object oriented code.
There are a lot of problems with C++, I agree, but fundamentally, objects should not be a problem as long as you use it well. (Though ,there is a fundamental problem with the fact that there is no standard for compilers… making it impossible to handle object oriented code compiled in other compilers…. that is a fundamental flaw with C++ imo)
I’m sincerely looking forward to Jonathan Blow’s new language… but that is still far away on the horizon for now and a whole other topic….
PS: talking about compilers… I’ve been waiting for constexpr to get supported in visual studio for years… I hate to rely on macros too much, especially as the compiler hats it just as much… when writing this I looked it up and it seems like it finally is available… but it took to damn long >_<… I have yet to try it though. Anyone here that have been testing it out?