Author: Ricardo Gibert
Date: 04:43:51 07/30/03
Go up one level in this thread
On July 30, 2003 at 03:51:35, Bo Persson wrote:
>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))
Why not compare with the following instead?
if (isKing(Piece))
if (isBlack(Piece))
>
>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 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.