Author: Amir Ban
Date: 06:51:24 11/06/97
Go up one level in this thread
On November 06, 1997 at 08:11:30, Bas Hamstra wrote: > >I agree, but that is not my problem, at the moment. If I understand you >well you say one can perfectly well work with one object, with >functionality inherited from other objects or one object being a >"cluster" of objects (several instances of smaller objects). Doesn't >matter which method you use. I agree. > >But my problem is: WHICH objects?I have a few hundreds C routines and I >now want to start in C++. Which routines to lump in which objects? > That's not so hard. Look at your routines parameters. Usually there will be one parameter that you can say that the routine does something on it, or out of it. You can then make the routine a method of the parameter type. If the routine initializes some structure (i.e. creates it) you can call it a constructor if you want (you don't have to), and so on. If you are in the habit of manipulating globals, this will be less obvious, but still doable. For example, if your eval function evaluates a node, you can now say that the node is the class, and eval a member function. If you are unsure of where you are going, you can take the path of incremental migration, meaning, use your original program for a start. Take all your existing structures and tell yourself that they are now classes (in C++ a class and a struct are one and the same). You can then convert some functions to become class members. Sooner or later you will understand better what is going on and you will be moving code fragments and defining structures in different ways to reach coherent classes. It's definitely not rocket science, but some practice is needed to understand it. Amir
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.