Author: Bo Persson
Date: 00:51:35 07/30/03
Go up one level in this thread
On July 29, 2003 at 20:02:03, Russell Reagan wrote:
>On July 29, 2003 at 16:34:36, Gerd Isenberg wrote:
>
>>Move is a class already, no virtuals, only inlined functions.
>
>Hi Gerd,
>
>Would you mind posting your move class declaration? I am always interested to
>see how people implement "simple" classes like this, because sometimes it ends
>up being not so simple :)
>
>Sometimes I think it's better to make classes for the simple things like Piece,
>Color, Square, etc., but it can be awkward to get them to work together
>correctly while maintaining the same speed you get with a simple enum or int.
The Piece class is of course just a wrapper around your int or enum. Using lots
of small inlined functions, you can get (at least) the same speed as with C,
while making the code much more readable.
I very much prefer code like
if (Piece.isKing())
if (Piece.isBlack())
over
if (Piece & KING_MASK)
if (!(Piece & COLOR_MASK))
because I find it much more readable. You also get all the Piece access code in
one place, "piece.h". If you later find that your new compiler prefers "((Piece
& COLOR_MASK) == 0)", you can change that in your isBlack() function and be
done. Very convenient!
>In
>a chess program, it might not be that beneficial to hide the implementation.
It can be very beneficial to hide the implementation, because then you can
change it if you find a better one later.
>
>Imagine if you hid all of the implementations to all of the parts of a chess
>program. You couldn't take advantage of 0x88 or bitboards or any of that neat
>stuff, because no other classes could know how your "board" class worked.
Other classes shouldn't care that much about how Board is organized. If they
want to know anything, they can ask the Board. :-) If it hasn't already got the
proper "question" to ask, you will have to write one *in the Board class* not in
the search or the move generator.
>Someone once told me that the goal of OOP is to write correct code, and since
>computer chess is such a heavily researched and studied area, we already have
>many "correct" ways of doing things. That is why we have all of the "standard"
>board representations and ways of doing things (like 0x88, bitboards, hash
>tables, etc.).
What's wrong with correct code? :-)
Also, I woudn't exactly say that computer chess is "solved" in any way.
> So maybe all of the benefits of OOP aren't as important in
>computer chess, but some are.
Maybe not. It also depends on what you mean by OOP. Some OOP "fundamentalists"
reqiure polymorphism and dynamic allocation for everything. That's probably not
very useful in a chess program. If you start out like:
void makemove(piece x, square from, square to)
{
delete Board->Square[from];
Board->Square[to] = new piece(x);
}
you are in deep trouble speedwise. Don't do that!
To me, finding the right abstractions is also part of the fun. Getting classes
like Piece, Square, Move, Bitboard, MoveGenerator, etc to work together without
them knowing each other's internal representation (and without get/set
functions), is great fun to me. Feels almost as good as seeing the piece images
make good moves on the screen...
Bo Persson
bop2@telia.com
This page took 0.01 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.