Author: Dann Corbit
Date: 12:57:47 07/23/02
Go up one level in this thread
On July 23, 2002 at 15:52:39, Russell Reagan wrote: >On July 23, 2002 at 15:31:12, Sune Fischer wrote: > >>>if (squares[i].piece().color() == BLACK) >> >>from a layman: doesn't look to me like that can be inlined, the compiler needs >>to know in advance what function to call to do that, but here color() depends on >>piece() which it won't know until runtime. > >I'm not sure about that, because there aren't different piece classes based on a >base class Piece. piece() just returns a Piece object, so I think the color() >method is the only one, unless I misunderstand something about C++. > >>BTW, you can do sq&1 to check the color of the square. > >That's how I handle it internally. I'm beginning to think I should scrap this >whole OOP approach, but then I inevitably run into something that I want to >change and wish I had taken the OOP approach. Round and round I go... It is easier to change an OOP design, I think. Use modelling tools like Rational Rose to make up your mind. When it is completely thought through, then generate the code and fix it up by hand. Every design changes over time. Look at the headers of Crafty. So the lesson to be learned is to make the classes as general as possible because you *know* they are going to take off in new directions from time to time. Use inheritance to specialize general objects. Use advanced, debugged tools like the STL to make your programming easier. On the other hand, if procedural thinking is easier for you (and it is for *many* people) then go ahead and write procedural code. Crafty, Yace, Phalanx, etc. are good evidence that procedural structure can produce excellent fruitage.
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.