code style question and droid limits

Discuss the future of Warzone 2100 with us.
Giel
Regular
Regular
Posts: 725
Joined: 26 Dec 2006, 19:18
Contact:

Re: code style question and droid limits

Post by Giel »

DevUrandom wrote:
Watermelon wrote: 3.I think converting to C++ will create some serious issues/bugs like the mixed memory management,like mixing up C-sytle 'malloc' and C++ 'new'...
That, increased complexity of the buildsystem and no obvious need for it makes me say: "We don't intend to partialy convert WZ to C++". And a full conversion aka rewrite is not intended either.
Well the buildsystem wouldn't increase that much in complexity really, not as long as you keep your C to C++ interfaces clean. Managing those interfaces will be a significant job though. Mixing malloc with new problems can be prevented by never passing pointers through your C2C++ interface. As for converting I'd have to say don't do a full conversion (at once that is, incremental => maybe). Partially converting however will still be difficult because of the awfully tight coupling of codepieces and compilation units (i.e. the source files). I'm experiencing this (the large coupling) now while rewriting (not converting) the sound library in C++. Reintegrating the new library into the C code takes significant amounts of time/trouble.

That said a conversion of parts is possible just not easy. So if you really want to convert a part, suggest what you want on the mailinglists (or forums, though most dev discussion takes place on the mailinglist) to obtain some feedback on what you want to convert.
DevUrandom wrote:
Watermelon wrote: I admit using C++ will speed up the development speed
Don't know about this...
C++ is most of the time more easily to use in an object oriented manner (e.g. representing droids as classes), so it will most likely increase development speed (if used properly). That excludes any required work to actually be able to use C++ features though.
DevUrandom wrote:
Watermelon wrote: and attract more attentions from developers
Possible. Even more would be attracted if we'd jumped on the C# hype...
Not me, C# really stinks IMO, plus C# is not backwards compatible with C, C++ is (it is designed to be). Although that is hardly the reason I think C# stinks, I simply don't like vendor lockins on the programming language level (nor any level really).
DevUrandom wrote:
Watermelon wrote: since C is already sort of underdog due to the lack of efficiency(reading/writing code wise,not performance wise)
In the end it depends on the programer, doesn't it?
And with a bad design you can create worse C++ apps than you could in C...
I agree, with a bad design you can create equally bad code in whatever language you use be it C or C++.
DevUrandom wrote:
Watermelon wrote: :o the current bottleneck of overall performance is not gamelogics,so the impact of performance of changing units cap/implementing new feature using C++ objects should be minor/unnoticeable imo.
Sadly true...
Well classes really add little if any overhead with a modern compiler (i.e. one after 2000 or so) compared to C. However gamelogics are indeed at this moment not the bottleneck so ruining them (in whatever language) probably won't have significant effect on performance.
DevUrandom wrote:
UrbanVoyeur wrote: OIC. I have to wrap my head around this C stuff. So its sorta kinda like an object, just without inheritance, extensions or polymorphs. ok.
Oh, WZ even got inheritance. ;)
I just fear that it is not officially supported by the C spec...
Have a look at the BASE_ELEMENTS definition.
Yes, well, ..., just don't try comparing it too much with C++'s (or any other OOP language's) inheritance.
DevUrandom wrote:
UrbanVoyeur wrote: Where is the current bottleneck?
The graphics engine is one of them.
Hmm, I'd say the graphics engine is "it"  ;)
kage wrote: ...
and certain c++ semantics such as the "friend" keyword (the usage of which is indicative of an underlying design flaw).
There are cases in which using the "friend" keyword is justified! The friend keyword should be used to protect object encapsulation, although it can be very easily abused to break encapsulation if it does that then you're doing bad.

Just look at my OpenAL source and buffer implementations here: http://svn.gna.org/viewcvs/warzone/bran ... nd/openal/ (source.* and buffer.*). This is a problem I can (because of the design of the OpenAL API) only solve with a) using "friend" or b) breaking object encapsulation entirely by using a public accessor (or worse make the ID number itself public) to the internal ID number.
kage wrote: in the end, many resources will point out that an interface can, in regards to group relationships between classes, achieve everything that classic inheritance can, and with much greater flexibility. on the small scale, every once in a while you'll find a problem for which extends is obviously the only clean solution (in which case you use extends), but for just about everything else requiring a class, an interface is the better choice (and interfaces are always a much much "cleaner" approach than c++ multiple inheritance).

the above is certainly something of a mini-rant, but is based on hard research by many other people (i can look up some old sources if people want); i won't even talk about the evils associated with the tendency of oo programmers to needlessly "overclassify".
Inheritance is actually primarily meant for the exact purpose of inheriting interfaces. Secondly it also can be an aid in preventing overclassification (although object composition sometimes might do a better trick).
kage wrote: at any rate, a "class relationship" in c++ is simply a compiler-imposed convention -- if we start to write up a virtual "interface/inheritance tree" diagram (if it's not apparent whether a struct is "extending" or "using" another struct, then it may need to be cleaned up), then the system in place might be much more usable to any developers new to the project, and it shouldn't be extremely difficult to maintain developer-imposed struct relationships.

i believe there's no inherent problem with us rewriting certain sections, or certain new sections in c++, but i'll always be there to point out that there are things that will always be more cleanly implemented when written in ansi c, and that, for all the "wonders of object oriented programming", it's vary easy to make it worse.
Erm, I believe that when you say "ansi c" you mean an imperative or functional programming style rather than an OOP style? If yes then I agree completely with you that for some problems that can be a better solution. But that's why C++ is called a multi-paradigm language, it enables the programmer to use multiple ways of solving a problem. That also puts the responsability with the programmer to do it correctly.

Anyway, if I insulted anyone with the above text, then let me say that was far from my intent, so please tell me if you felt insulted so I can attempt to prevent it in the future.

I personally do believe C++ is more powerfull than C because it gives the programmer more tools than C offers. More tools however means more responsability, and some people (whether programmer or not) simply can't deal with responsability (or large amounts of it).

Plus keep in mind: (almost) all C code is valid C++ code as well. (The few cases of incompatibility between the two usually indicate poor style anyway, except maybe for using symbol names in C which are keywords in C++, e.g. class, virtual).
"First make sure it works good, only then make it look good." -- Giel
Want to tip/donate? bitcoin:1EaqP4ZPMvUffazTxm7stoduhprzeabeFh
Giel
Regular
Regular
Posts: 725
Joined: 26 Dec 2006, 19:18
Contact:

Re: code style question and droid limits

Post by Giel »

UrbanVoyeur wrote: Sound like something I can do - move it to the wiki.  I'll try to follow the same basic organization of the old docs, unless anyone has other ideas.
If you think you can do it, I'd say go ahead. But rather than using the same organization I'd say don't rigidly use that organization but use your own style if you think it fits better.
"First make sure it works good, only then make it look good." -- Giel
Want to tip/donate? bitcoin:1EaqP4ZPMvUffazTxm7stoduhprzeabeFh
User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: code style question and droid limits

Post by kage »

UrbanVoyeur wrote: Sound like something I can do - move it to the wiki.  I'll try to follow the same basic organization of the old docs, unless anyone has other ideas.
i agree with giel: don't be afraid to reorganize it -- the operating principles behind a wiki are vastly different than those regarding a fairly static archive like the docs project. also, if you set out a basic (or better) set of organizational guidelines, and would like the help, i can also work on converting some of those documents.
Giel wrote: Anyway, if I insulted anyone with the above text, then let me say that was far from my intent, so please tell me if you felt insulted so I can attempt to prevent it in the future.
i didn't see anything that could be interpreted as an insult: you were quite objective in general, and made a number of good points. well, except for the c# stuff, but yes, anything locked-in to a specific vendor really does stink.
Last edited by kage on 23 Mar 2007, 13:08, edited 1 time in total.
Giel
Regular
Regular
Posts: 725
Joined: 26 Dec 2006, 19:18
Contact:

Re: code style question and droid limits

Post by Giel »

kage wrote: i didn't see anything that could be interpreted as an insult: you were quite objective in general, and made a number of good points.
Well that was my intention to remain objective, but you never know when you fail to do so.
kage wrote: well, except for the c# stuff, but yes, anything locked-in to a specific vendor really does stink.
Hmm, at (one of) my current education(s), which is Computer Engineering (most programming is on embedded systems). My school is somehow trying to force me/us into using .NET stuff. (Apparently was a decision made by school management, not by teacher's staff). So I'm like WHAT!?? do I need to write C# for a 16bit processor with only 8kb of memory (not to mention that C# doesn't translate directly to assembly and would need a JIT compiler as well)?? Anyway that topic is now over and .NET is officially banned from computer engineering now (now if only the required usage of Borland's C++ libraries would be banned, since they're not standard compliant). My point however is that C# (or other .NET stuff) is mostly favored by A) people who don't know anything else than MS only programming languages, or B) people who don't know anything about programming at all.

Anyway that ^^ (taking away my freedom to choose my own programming language without a proper reason) really has made me more aware of vendor lock-ins (and dislike them more than I already did).
"First make sure it works good, only then make it look good." -- Giel
Want to tip/donate? bitcoin:1EaqP4ZPMvUffazTxm7stoduhprzeabeFh
User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: code style question and droid limits

Post by kage »

Giel wrote: Hmm, at (one of) my current education(s), which is Computer Engineering (most programming is on embedded systems). My school is somehow trying to force me/us into using .NET stuff. (Apparently was a decision made by school management, not by teacher's staff). So I'm like WHAT!?? do I need to write C# for a 16bit processor with only 8kb of memory (not to mention that C# doesn't translate directly to assembly and would need a JIT compiler as well)?? Anyway that topic is now over and .NET is officially banned from computer engineering now (now if only the required usage of Borland's C++ libraries would be banned, since they're not standard compliant). My point however is that C# (or other .NET stuff) is mostly favored by A) people who don't know anything else than MS only programming languages, or B) people who don't know anything about programming at all.
actually, *some* parts of .net are (sadly) actually *very* good in a windows-heavy environment -- a few components of .net are oriented towards distributed, fault-tolerant "applications", which means that you can program a distributed .net application that will, as a whole, run on 5 windows machines as stably as if it were run on a single foss *nix, since it's fairly unlikely that all of the windows machines will crash at the same time, and it's probable that, of the 5 machines in this example, at least 2 of them will be running at any given time. so, for all the corporate execs and government agencies that are heavily influenced by microsoft's multi-decade long propaganda campaign combined with the bandwagon effect, at least their customers won't be as likely to fall victim to such misinformed decisions (like using windows for any kind of server). on the other hand, pretty much every other use of .net (98% of the .net stuff the average windows user encounters) is definitely unwarranted, and can be attributed to the "framework hype" era we seem to currently be living in. in corporations, it seems to be used increasingly as a placebo, blaming their software problems on having not had any "effective solutions prior to .net", rather than coming to the realization that they need to stop hiring code monkeys. note that this applies in large to most examples of "framework" use (not just .net), when they are used "as a matter of course"
Last edited by kage on 24 Mar 2007, 02:11, edited 1 time in total.
Post Reply