C++ and KOS

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
User avatar
RyoDC
Mental DCEmu
Mental DCEmu
Posts: 366
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Wed Mar 30, 2011 12:13 pm
Has thanked: 2 times
Been thanked: 0

C++ and KOS

Post by RyoDC »

This question has recently emerged, and I've always wanted to ask.
I never see a program in KOS (except one example in example dirs) that uses functionality of c++ language, I mean, classes, or virtual inheritance, all made as a single structures and methods, divided from them.
I just thought, why do not split up all this in semantic parts?
It would be extremely useful, to had a class that contains a structure and all methods tied to it in one instance.
For example:

Code: Select all

Matrix A({{..},{..},{..},{..}});
prv->pushMatrix(&A);
pvr->polyRotate(25.f,0.f,0.f);
pvr->polyMove(dx,dy,dz);
pvr->setParams(&params);
pvr->startRender(); //and so on
Well, this code had a logic mistake, 'cause matrix translations and vertex operations do not performed by a pvr processor (it has no means to do it), it can be only performed by a central processor, who has it means to do it, but as a example how things should be for programmer (let it be some another class who performs calculations).
As far as I concerned, C++ possibilities can be used (compiler eats them), but in Kos programs they are very rarely used. Just wondering why.
How do I try to build a Dreamcast toolchain:
Image
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: C++ and KOS

Post by BlueCrab »

The main reason people don't use C++ is that they don't really find a need to do it.

In my opinion, there are things that C++ (and OOP) lends itself nicely to, and there are plenty of things that it doesn't. For instance, writing GUI programs on a normal OS is something that lends itself quite nicely to OOP. I have written both C and C++ GUI programs before, and I have to say that the former is generally painful and not a fun experience.

Emulators are an area where OOP is generally silly and just gets in the way. Operating Systems are another area that is like that.

Games, its a tossup. If OOP is baked into the design of the game it can be quite a nice thing to have. But at the same time, its not a necessity by any means. Some people don't find it helpful, some do.

With the patches that KOS has for GCC and Newlib and such, KOS fully supports C++ as well as Objective C (and Objective C++). If people want to design a C++ library to wrap around KOS, they certainly could do so. Heck, I did just that back when I was still working on writing a game actively. That said, in the past, there were plenty of issues with using C++ with KOS. Some things didn't work reliably, if at all (such as exceptions, and for a long time the STL in any program that used threads). The fact that you don't see much Dreamcast stuff using C++ probably reflects that state, as that's when most of the active development was still going on.

In the end, it all boils down to personal preference. Some people like the OOP approach, some do not. Its certainly not something I would ever force on people using KOS. Also, keep in mind that all of this stuff does introduce overhead. Virtual functions, especially. Extra overhead is probably not something you want a lot of in a Dreamcast program. :wink:
Ex-Cyber
DCEmu User with No Life
DCEmu User with No Life
Posts: 3641
Joined: Sat Feb 16, 2002 1:55 pm
Has thanked: 0
Been thanked: 0

Re: C++ and KOS

Post by Ex-Cyber »

Another thing is that a lot of OO libraries/runtimes/frameworks are built by people who think of real-time applications as a small esoteric corner of the universe, and hence don't optimize for predictability/consistency of performance. For example, they don't care if some iterations of your game loop take 100 times longer than is typical. In C or assembly language, calling these kinds of services is an explicit action; in C++ and most other OO languages, it can happen behind your back unless you intentionally take precautions to avoid it (the big one being to avoid creating/destroying objects in your game loop).
"You know, I have a great, wonderful, really original method of teaching antitrust law, and it kept 80 percent of the students awake. They learned things. It was fabulous." -- Justice Stephen Breyer
User avatar
RyoDC
Mental DCEmu
Mental DCEmu
Posts: 366
Joined: Wed Mar 30, 2011 12:13 pm
Has thanked: 2 times
Been thanked: 0

Re: C++ and KOS

Post by RyoDC »

Despite I respect your opinion and your experience, guys, I can't agree with two things that you mentioned:
1. Overhead. Class itself in memory consist only of local members and pointer (4 byte) to a vtable. So it would probably be the same as it will be if we create a structure with separate methods, bounded with the treatment of that data. So this so-called 'big overhead' will result only in four Extra bytes needed for storage of vtable pointer. Well, I described only one example or a possible appearance of such a method (when we have a base abstract class, and an inherited classes), of course I didn't mentioned diamond inheritance or some more complicated cases of virtual succession.
2. About n*n iterativity. As far as i read, for example, from this book - http://www.agner.org/optimize/optimizing_cpp.pdf - it says, that usage of STL is conversely, more recommended, the usage of built-in support of dynamic arrays cause of more trusted realiabilty, scope controlб and predictable speed of acces to the element in the container class (as you all already knew, those times are described as a various variants of O(n) function for each class).
So it's even more stable.
Well, you were, probably, not talkin' about STL (I wonder, does it found any working realization on Dreamcast platform?), you were more likely have talked about some other libraries, having an OOP-interface, but anyway, I should be glad to receive your description about such a cases in samples.
Thanks.

Also found interesting topic, where guy meets with problem of using stl in kos program:
viewtopic.php?f=29&t=99655
How do I try to build a Dreamcast toolchain:
Image
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: C++ and KOS

Post by BlueCrab »

First off, the overhead is not in storing the vtable, but in excessive use of it versus normal function calls that are bound at compile time. It does take time to look up entries in the vtable, and with how little cache the SH4 has, those lookups into it tend to start adding up quick.

Plus, as Ex-Cyber says, many OO libraries do all kinds of things that do not lead to acceptable performance in a real-time-like system. For instance I've seen an OO library that every frame builds a std::vector of items, sorts it, uses it in drawing the scene, then deletes it. That stuff all takes time.

Also, the STL works fine. Its part of GCC, and as long as you're using a properly patched GCC/Newlib it shouldn't be any real problem. Of course, you have to use it properly and avoid things like what I said above if you want sane performance. :wink:
Ex-Cyber
DCEmu User with No Life
DCEmu User with No Life
Posts: 3641
Joined: Sat Feb 16, 2002 1:55 pm
Has thanked: 0
Been thanked: 0

Re: C++ and KOS

Post by Ex-Cyber »

RyoDC wrote:predictable speed of acces to the element in the container class (as you all already knew, those times are described as a various variants of O(n) function for each class).
Yes, but watch out for the words "amortized constant time" (or similar) in those descriptions. It's a way of saying that a sequence of n operations takes O(n) time without guaranteeing that each individual operation takes O(1). std::vector::push_back is an example.
"You know, I have a great, wonderful, really original method of teaching antitrust law, and it kept 80 percent of the students awake. They learned things. It was fabulous." -- Justice Stephen Breyer
Post Reply