Experiment: C++ port of ottd

[KUDr]

I just wanted to try it.
It took me 3 days to compile it as C++ (+ 3 days more to eliminate throwing of new asserts I added).
Then some improvements (new classes for direction, track, trackdir, and so on.)
Then new tile indexing scheme + some other experiments.
PBS works much better now (no random crashes, can reverse always).
Was it bad idea?

Then I was asked to share it.



So here it is (thanks to boekabart):

[DaleStan]

Three questions:
1) How does the memory usage compare?
2) How does the CPU usage compare?
3) How does the readability compare?

[KUDr]

DaleStan:

1) How does the memory usage compare?
- no difference by language change

2) How does the CPU usage compare?
- in Release: the same
- in Debug: ca +50% - new inline functions (methods + operators) that are not inline in Debug builds

3) How does the readability compare?
- well, the readability could improve by the time. But it has nothing to do with C++. Only the new code, if it is well designed can give you better readability, lower maintenance costs and so on.

The biggest benefit I see in C++ is that compiler doesn't allow you to do typical mistakes like using trackdir instead of track without calling some conversion method. In C it is bit harder to see such problems. And there were many of them.

[Sacro]

Slight problem, PBS is no longer in the trunk so your patch needs updating.

I'm sit digging at your patch at the moment, trying to extract just the PBS fixes, I don't suppose you are able to help me with this task are you?

[KUDr]

Sacro:

No, this patch doesn't need update. As you can see from the subject, this is experiment.

I wanted to try and compare C++ vs. C. Not to fix PBS. I am very satisfied with the result as it can help break the myth about "slow C++ vs. fast C". There is only bit different syntax for the same things and much more strict type checks. It was obvious that changing source language can't change the execution speed.

But the PBS related code was the most problematic part for the compiler to deal with. I needed to do many changes in the PBS code to suppress errors and later also asserts (i.e. lookup behind table overruns) so please test it as it is first. And then decide if you want to isolate PBS from it. It can be the same scrap. Don't belive me, just try it.

[LordOfThePigs]

Hmm...

Heh, it's going to be quite tough to rewrite the whole code to use a purely OO aproach.

Session Start: Wed Jan 11 22:12:48 2006
Session Ident: #openttd
[22:25:36] <Tron> so...
[22:25:47] <Tron> ottd consists of 119 object files
[22:26:25] <Tron> these have 1366 inter-object-dependencies (object file A uses a variable/calls a function in object file B)
[22:26:43] <Tron> 108 of these object files form a strongly connected component

The slow C++ vs fast C as you say is valid only if you use a purely OO approach. Inheritance does bring quite and overhead. Replacing a few structures by classes and the syntactical changes won't make any difference, the compiler output is probably going to be the same anyway...

[boekabart]

Being a CPP programmer professionally, my first instinct when I starte programming in OpenTTd was also 'why not C++'. But, now that I'm used to it, the only thing that I think really misses in C that OpenTTd can benefit from, is the strong types checking.
Therefore I think it's a really good experiment that was done (if it's done been accurately, of course), so I think it would definately be a good idea if everyone who wrote a specific part would take a look at when KUDr had to do to make it compile as C++. Lot of changes will be trivial, but as he says himself, there were lots of apparently real type errors. I think the original coders (or people who know and understand the code really well) should take a look at those.
(And I mean not just HackyKid (PBS) )

[bobingabout]

i think what sacro meant is that you fixed PBS, but nobody else has yet, he wants to use your code to help him fix the current PBS, which is kinda difficult since PBS has been removed from the SVN for the up-comming stable release.

[Tron]

I am very satisfied with the result as it can help break the myth about "slow C++ vs. fast C".

Welcome in the 21st century, you're ten years or so late.

[Tron]

Hmm...

Heh, it's going to be quite tough to rewrite the whole code to use a purely OO aproach.

Session Start: Wed Jan 11 22:12:48 2006
Session Ident: #openttd
[22:25:36] <Tron> so...
[22:25:47] <Tron> ottd consists of 119 object files
[22:26:25] <Tron> these have 1366 inter-object-dependencies (object file A uses a variable/calls a function in object file B)
[22:26:43] <Tron> 108 of these object files form a strongly connected component

Object files have nothing per se to do with object oriented programming.

The slow C++ vs fast C as you say is valid only if you use a purely OO approach.

There is no such thing as "pure object orientation". The paradigm of object orientation alone isn't enough to form a programming language.

Inheritance does bring quite and overhead.

bulls***.

[LordOfThePigs]

Object files have nothing per se to do with object oriented programming.

Well, not really, the point was that even if you have tried to keep the things logically in separated files, you still ended up with basically the whole code forming a strongly connected component. From there, I wish good luck to whoever tries unspagethising the code in order to form meaninful classes and object relations...

There is no such thing as "pure object orientation". The paradigm of object orientation alone isn't enough to form a programming language.

That might have been a poor choice of words. I meant that you reduce the use of global functions to the strict minimum and encapsulate whatever functions are still global as static functions in the correct class.

Inheritance does bring quite and overhead.

s***.

Ok, I'll have to admit that I'm not an expert here, but doesn't every object keep a function table, and each level of inheritance encapsulates the super-class object (including the function table). Doesn't that bring memory overhead?

[KUDr]

Tron:

thanx. What I see here is total ignorance of some "programers" that think that using C++ means slower because of language. No. This is because of more abstract design of usual OO code and programers that don't care about implementation of the classes/methods they use. It is lack of knowledge that can lead to the ineffective code, not the language itself.
But what the language can bring you is better isolation of modules. One example:
If you want to change tile indexing scheme in the current ottd, or add assert(tile < MapSize()) into tile indexing, you must first of all replace all "m[tile].m3" references by something like "GetTileByIdx(tile)->m3", then you have it isolated and you can play with asserts or tile indexing. In C++ you can do such changes in more clear way.

On the oposite way C gives you much more freedom. You don't need to care about types of variables, arguments and so on. You can use Trakdir instead of Track, if you want (and if you know what are you doing). The only problem is that nobody is perfect and everybody does mistakes. And C compiler doesn't warn you about this kind of mistake.

This is why I prefer to use C++ compiler.

[Korenn]

most of the inheritance and other object functionality only exists pre-compile time. So that will not change performance.

[Tron]

Ok, I'll have to admit that I'm not an expert here, but doesn't every object keep a function table, and each level of inheritance encapsulates the super-class object (including the function table). Doesn't that bring memory overhead?

Short answer: No (you're confusing inheritence, aggregation, polymorphism and probably some more)
Long answer will follow tonight, when i have more time.

KUDr: Don't tell me, I know what a hammer and a skrewdriver are for. I also know you can use a skrewdriver as a hammer if you don't have the latter at hand.

[CobraA1]

IMHO, switching to C++ would be great. OOP allows for easier creation of data structures and algorithms that use those data structures. I'd rewrite my queue code in OOP in a heartbeat.

AND I'd have a larger incentive to implement more complex stuff such as custom airports, beause it would be much easier to implement (I'd still need to figure out the map, sprite, and UI stuff, though ).

Heh, it's going to be quite tough to rewrite the whole code to use a purely OO aproach.

No need to, actually. All the existing stuff can still use the older approach if you wish. C++ would merely be allowing future patches to use OOP. IMHO, not having OOP was a severe limiting factor for creating proper data structures for my queueing code.

Ok, I'll have to admit that I'm not an expert here, but doesn't every object keep a function table, and each level of inheritance encapsulates the super-class object (including the function table). Doesn't that bring memory overhead?

Yes and no. Today's modern compilers are intelligent enough to optimize away unneccessary overhead and inline stuff when possible, and honestly I've never heard of a program being too slow due to this overhead. IMHO, the fear is unfounded.

And, as Tron indicated, you're confusing some stuff.

Also, OOP is not required for C++. If you really need to do some things tlhe old way, you can do so. Lest you forget, C++ is an extention of C - anything you can do in C, you can still do in C++.

[DaleStan]

I'll try to make a concise summary here, but your best bet is probably to visit the comp.lang.c++ FAQ, and read sections 19..24.

Ok, I'll have to admit that I'm not an expert here, but doesn't every object keep a function table.

Only for virtual functions, and even at that, vtables are static; they are per-class. Objects only contain vtable-pointers.
Each class that contains vfunctions maintains a vtable for its objects to call through, and each object of those types points to the appropriate vtable.
If foo is a virtual, then "obj.foo();" expands to something like "obj._vtableptr[_foo]();", where _foo is the offset in the vtable of the pointer to foo -- a compile-time constant.

Compared to direct, non-virtual call, function-call-through-vtable typically adds two extra loads (mov reg, [ptr]) before the call.

Constructors (including the copy constructor), the assignment operator, and the destructors can easily involve much function-call overhead, but they are relatively rarely used, and may well be inlined anyway, depending on their complexity an the size/speed tradeoffs desired.