>Nah. As far as I hear, most of them moved away from OOP a long time ago. "Component systems" have been hot for more than five years.
Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games.
>Come on, what a GUI does vs a non-GUI "realtime" app is pretty trivial.
You'd be surprised. A guy is not just "call x program with some flags" as you might believe.
Something like a NLE editor for example or even an IDE can have GUI needs that go far beyond hundreds of thousands of LOC...
(Not to mention that I was referring to GUI libraries themselves, complex beasts on their own, not GUI code as used by applications to build their GUIs).
> Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games.
Sure, it's C++, and in my perception much C-style C++. And C++ != OOP.
> (Not to mention that I was referring to GUI libraries themselves, complex beasts on their own, not GUI code as used by applications to build their GUIs).
I will admit I haven't written a NLE program, but integrating complex logic with a complex and hard to understand GUI framework like Qt, meaning there are a lot of states to synchronize, is a lot of inessential complexity. I'm pretty sure it's much easier when you only use GUI primitives and do most of the coding on your own. E.g. a standard box layouting and event bubbling algorithm can't be that much work, and it's MUCH MUCH easier to do it on your own and choose the appropriate structure, instead of writing many helper classes trying to bend the rigid framework.
Taking the example of a NLE program - it has lots of domain-specific state which you must absolutely understand if you want to write such a program. And you absolutely must have a vision how this state should be reflected on the screen. Choosing how to do it is a lot of work. Actually drawing it should be the smaller amount of work, by far. Just separate the state from the GUI library. If you scatter it over thousands of objects, inheriting implementations that you don't own and don't understand - well, of course! that's really hard.
>Taking the example of a NLE program - it has lots of domain-specific state which you must absolutely understand if you want to write such a program. And you absolutely must have a vision how this state should be reflected on the screen. Choosing how to do it is a lot of work. Actually drawing it should be the smaller amount of work, by far. Just separate the state from the GUI library. If you scatter it over thousands of objects, inheriting implementations that you don't own and don't understand - well, of course! that's really hard.
My point was rather than just the essential GUI functionality and interactions for such a program can be very complex.
In other words, when to show this or that, how to structure code to show it fast, how to present it best, etc is also essential logic (not some afterthought on top of the domain logic), and it can also be super-hard to code (depending on the kind of program).
It's pretty trivial, at least not any sort of GUI-specific hard problem. There is only a low number of objects on any given screen. Don't raster pixel-by-pixel on the CPU, of course.
>> Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games.
Sure, it's C++, and in my perception much C-style C++. And C++ != OOP.
Sorry, meant to write "good old OOP still rules the day".
Nope, that's just hype. Good ole C++ still rules the day, except for specialized (and smaller in scope and speed needs) games.
>Come on, what a GUI does vs a non-GUI "realtime" app is pretty trivial.
You'd be surprised. A guy is not just "call x program with some flags" as you might believe.
Something like a NLE editor for example or even an IDE can have GUI needs that go far beyond hundreds of thousands of LOC...
(Not to mention that I was referring to GUI libraries themselves, complex beasts on their own, not GUI code as used by applications to build their GUIs).