Am Montag, 8. Januar 2007 19:43 schrieb Christian Ohm: > 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. > > > >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. > > 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++. > > 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. Basically I think that's the maintainance problem... Actually I didn't even know that it is possible to link a C application against a C++ lib, because I thought the C++ ABI is incompatible to the C ABI...
--Dennis
pgpb14ILemyA9.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
