At 10/5/12 08:50 AM, egg82 wrote:
actually, I was attacking your argument that "not everything has to be OOP"
no, I suppose it doesn't, but why in the world would you want to program that way?
C is a hell of a lot faster if you know what you are doing, OOP in C++ is just an illusion that the compiler feeds you, in reality all your classes turn into structs at runtime and every member function will turn into a procedural function that receives the this pointer as an extra argument (visualc will pass it through rcx, gcc not sure). If you don't use virtual functions it's pretty much the same, but virtual tables and inheritance take their toll on memory management, every call to the new operator will also have to place the vtable pointer at the start of the object and overall there's stuff that happens in the background that make it more desirable for people to write code in C (extern "C" would be a good example for this)
Sure, somebody writing a game is going to use an OOP approach, but if he's asking basic questions, rather than specific ones, chances are designing the game with OOP from the start is going to create a flawed design.what flaws are you thinking of that could arise from the use of OOP? From my understanding (and I made an entire thread about this) it's a very well structured and organized method of programming.
God objects, strongly coupled components, plus that it's horribly easy to make wrong decisions like keeping a transform matrix as a part of an object as opposed to having it in a contiguous space where it can benefit from cache line locality, OOP is not without it's flaws.
It's a lot more straight forward to procedurally write it especially when dealing with events.Actionscript 3 is event-driven, and people still very highly recommend the use of FlashDevelop, which forces you to use OOP concepts.
I can't really see how this is an argument in favor of anything related to the C/C++ world, adding an ECMAScript implementation to the discussion will just prove what polym is trying to tell you, that you are blindly following a trend rather than acknowledge the benefits.
In this case, what polym is trying to say is that the SDL event API is procedural (reference and .h file), if you want to use OOP you have to add an abstraction layer, which depending on your setup isn't necessarily a good idea, why propagate an object reference when you can look for a specific event (SDL_HasEvent, not SDL_PollEvent).