Christian Ohm schreef: > On Sunday, 7 January 2007 at 14:17, Per Inge Mathisen wrote: > >> On 1/7/07, Giel van Schijndel <[EMAIL PROTECTED]> wrote: >> >>> Well the problem with a local tree would be that I would only be able to >>> commit anything but incremental changes without breaking things (i.e. >>> without breaking the trunk). >>> >> Maybe I should not use the word 'tree'. What I mean is another local >> copy of the trunk. >> >> If it works in your local copy, it will not break the trunk. Whenever >> I want to develop something bigger, I make a separate local copy for >> that. So I have one copy for small commits, one for the memory patch, >> and so on. That way I can integrate other people's changes that are >> done while I am developing my stuff merely by doing "svn up" on each >> copy. This seems to me the easiest way to work (alone) on bigger >> changes. >> >> I am not telling you not to create a branch, I am just trying to see >> if you really think this is the best way to work on it. As I said, I >> doubt branches give you anything but more work unless you are multiple >> people working on the same changeset. >> > I see several advantages to a public branch compared to working just on > a local copy: > > - Other people have the chance to comment, test, report bugs, help with > coding... (impossible if noone knows what you're doing). > > - Smaller changes. On a local branch you can only make one big patch > that has to work (more or less) before being applied. A SVN branch > records your steps while working, enabling people to follow your work, > and understand the new code easier, as well as giving more > fine-grained changes to look for eventual bugs. > (Of course you can use a local revision control system to work with > and record your patches, and when it all works, apply those > subsequently to SVN. But that's more work, and you lose the "time > factor" that let's people follow your progress.) > > I am not saying that this will happen with a public SVN branch, but with > a local branch, it can't even happen. > The part about "one big patch" is really what I was trying to argue for: making it be smaller changes is probably better. Plus code-review by others (while it is still doable, which it wouldn't be if you'd use one big patch) is *always* good and I do mean always (actually using someone's comments on code will depend on the specific situation however). >>> C++ provides easier ways of error handling (e.g. exceptions), plus it >>> natively provides OOP. I am aware that some level of OOP abstracting is >>> provided in the current warzone codebase since the used technique >>> however is not native to the language it is harder to maintain. >>> Especially RAII is rather difficult to implement using C (whereas C++ >>> provides constructors/destructors and operaters new/delete for an easy >>> implementation of RAII). >>> >>> And secondly the only thing becoming more difficult to maintain should >>> be building (i.e. as far as I see). Which I think should be made more >>> easy by the creation of a C interface and the fact that the this C++ >>> implementation is kept local in a library. >>> >> My experience from work, where I maintain a large codebase of mixed C >> and C++ code, is that such mixing is a maintenance nightmare. I do not >> want this unless there is a very good reason for it, and what you are >> providing are arguments to convert all of Warzone to C++, which, even >> if you buy those arguments, is a totally different discussion. >> Agreed, you shouldn't assume someone is available until the end of time. So I'll have to make sure it is easily maintainable. To me that means: * writing lots of (*meaningful*!!) comments in the code; * don't use magic numbers; * using the STL (or OpenAL in this case) wherever possible _and_ meaningful; * limiting shared resources (i.e. functions and variables); * use as little macros as possible (preferably include guards only); * use as little cross-referencing across source and header files as possible, aka avoid cyclic dependencies;
and some more. But then again all that ^^ is properly summarized by Christian, I quote "you can write bad and good code in both C and C++". > Hm, and the current code isn't a maintenance nightmare? I think using > some C++ to encaspulate stuff will make things better, not worse (if > done right, of course, but you can write bad and good code in both C and > C++). That might be possible with C as well, but to me it seems more > natural in C++. > Indeed, abstracting your code (or declarative programming as some people like to call it) is more natural to C++ than it is to C. Which on its own improves maintainability. > What I don't agree with is making a C interface to a C++ interface to > OpenAL - seems like duplicated work to me. I'd just use C++ in the code > and compile the complete game with a C++ compiler. But that's just me, I > guess there needs to be some decision about how to use C++, or we just > follow the usual "those who do decide" approach. Well the C-interface all depends on, as you pointed out, whether a C++ compiler will be used for the entire project or not. If however a C interface is created it is later on always possible (though not necessarily easy) to drop that interface and move all calls to the library directly in the code. Then as for a decision upon C++ usage, I think that eventually it will no matter what all depend on "those who do". That doesn't mean however IMO that those are the only ones who should decide about this. -- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
