Rich wrote:
So what I'm thinking is that I'll just take all the *.c files on the branch and save them as *.cpp. Then address any compile errors or warnings that might result. It will still be a gigantic 1990-style C program, but now when we add new code we can add it as objects. Existing code can be incrementally refactored(*) into objects.
I don't have a problem with this strategy but I do have a question about timing. How far along are we on getting the entire feature set working? Should we get it to releasable form and then move the language? A related question might be, what is the speed relative to the DOS version? Do we need a step of optimizing some of the bottlenecks? Perhaps it's not a question of one or another, maybe these are two independent efforts. I realize that you are proposing incremental refactoring, so maybe timing is not an issue. On a tangential note, after bravely predicting my availability in February, I realized too late that it's not just the disruption of redoing one's house that takes up time, but also moving back in when the project is "done". Be that as it may, I'm ready to begin looking at this project more closely. Life is much simpler now that we are not camping out in our own house. My computer room is still a bit of a mess, but then I am perpetually organizing it :-) Should I start with the 2003 compiler you sent or get the 2005 version? I saw your note a few days ago about maintaining two project files. Since I haven't invested any time getting set up yet (other than keeping current with CVS), let me know if it matters which compiler I start with. On a third topic, would you be open to migrating to Subversion, or would you rather stick with CVS? As you probably know, while SVN aims to be a better CVS, it is significantly better in a number of ways. Two that come to mind are versioning directories and supporting renaming, and the fact that it doesn't version individual files but rather versions the whole project. This latter takes getting used to since changing any file bumps the version up, but in many cases this is what we want, since it automatically tells you which file revisions correspond to a particular patchlevel without any special tagging. I only suggest this only because I am using subversion at work and I'd prefer to learn one system well, and subversion does seem to be becoming more of a standard. However since you are doing the lion's share of the work, if you don't like this idea we can stick with CVS. I would understand the argument that CVS meets our needs, and migrating would just distract us from the task at hand. Having said that, and having used both CVS and SVN, I'd have to say SVN is a serious upgrade that might have productivity benefits down the road. Tim