Author: Dan Newman
Date: 02:17:56 08/19/00
Go up one level in this thread
On August 18, 2000 at 20:13:23, Dann Corbit wrote: >On August 18, 2000 at 05:07:09, Dan Newman wrote: >[snip] >>OTOH, I have occasionally considered attempting a full blown OPP chess >>program complete with pools of chess pieces with overloaded new so that >>(for instance) on pawn promotion I could delete the pawn and new a queen... > >Dumb as a box o' rocks observation: >Since the absolute "max" of posible chessmen is known, why hot just preallocate >a "box" of chess pieces with enough spares for either side. Captured >pieces/pawns go into the box and promoted pieces are pulled from it. > >At the start of a game, it contains: > >White rooks: 8 >White knights: 8 >White bishops: 8 >White queens: 8 >White pawns: 0 >No White king slot >Black rooks: 8 >Black knights: 8 >Black bishops: 8 >Black queens: 8 >Black pawns: 0 >No Black king slot > >If you wanted to carry the metaphor further, you could have all the starting >chess men in the box to start with and construct the board by pulling pieces and >pawns out of the box. > >Each piece could have a bit that means in use/in box to use for error checking. > >Sounds like bizarre overkill, perhaps. But if your evaluation removes hundreds >of pieces or promotes hundreds of pieces during a search, it might be useful to >do it that way. This is more or less what I had in mind with the pool idea. When, frex, "new WhiteQueen" gets executed, the overloaded new would find an unused white queen and return a pointer to it. This would be a lot faster than going through the memory allocator... A neat thing about this scheme (of making a class for each piece type) is that you can put the move generator code into those classes and then simply iterate through the piece lists calling the virtual move generator functions to generate the moves. OTOH, this is also going to add a lot of function call overhead to the program. If you are doing bitboards though, this isn't really an option. Instead of pieces being relatively heavyweight objects, they are grouped together in bitboards by type... I think it may be a mistake (when deciding what classes are needed to do a chess progam in C++) to identify the physical objects involved in the game and make classes for them. (That's the first thing I thought of when first attempting this a few years back. The first two sorts of object I though of were the pieces and the board. Beyond that what else is there? I quickly decided *that* was a mistake when I didn't see an easy way to turn pawns into queens.) Instead (I think) you really need to look at what "things" are needed to play the game (like search, eval, moves, state info, etc.) and encapsulate those things instead--when it makes sense to do so. In my current chess program I've only haphazardly OOP'ed stuff in a few places where it helped. For instance, my move is a class, and I get at its from and to-square coords via member functions so that I can experiment with move representation without having to do massive changes to the code. But for the most part I just use C++ as a "better" C. -Dan.
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.