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.DevUrandom wrote: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.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 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.
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:Don't know about this...Watermelon wrote: I admit using C++ will speed up the development speed
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:Possible. Even more would be attracted if we'd jumped on the C# hype...Watermelon wrote: and attract more attentions from developers
I agree, with a bad design you can create equally bad code in whatever language you use be it C or C++.DevUrandom wrote:In the end it depends on the programer, doesn't it?Watermelon wrote: since C is already sort of underdog due to the lack of efficiency(reading/writing code wise,not performance wise)
And with a bad design you can create worse C++ apps than you could in C...
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:Sadly true...Watermelon wrote: 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.
Yes, well, ..., just don't try comparing it too much with C++'s (or any other OOP language's) inheritance.DevUrandom wrote:Oh, WZ even got inheritance.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.
I just fear that it is not officially supported by the C spec...
Have a look at the BASE_ELEMENTS definition.
Hmm, I'd say the graphics engine is "it"DevUrandom wrote:The graphics engine is one of them.UrbanVoyeur wrote: Where is the current bottleneck?
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.kage wrote: ...
and certain c++ semantics such as the "friend" keyword (the usage of which is indicative of an underlying design flaw).
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.
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: 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".
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.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.
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).