Author: Anthony Cozzie
Date: 14:27:31 02/13/04
Go up one level in this thread
On February 13, 2004 at 16:09:08, Russell Reagan wrote:
>On February 13, 2004 at 15:04:31, Anthony Cozzie wrote:
>
>>However, your board structure is at the heart of everything you do -
>>make/unmake, eval, movegen, search, everything. You are simply not going to be
>>able to abstract this away without a _large_ performance hit.
>
>A point of clarification: "using classes" does not always mean "modular". Using
>a class to represent the chess board shouldn't need to cause any overhead at
>all. The main purpose of a chess board class, IMO, is to maintain the validity
>of the private data. Speicifically, the board should match up with the piece
>lists or bitboards.
>
>I am talknig about encapsulation, while I think you are talking about
>modularity. I confused the two for a long time, and I agree that if you try to
>make everything completely modular, you can take on huge performance hits.
>
>For chess, I say throw modularity out the window for the most part. Modularity
>is where you treat each object like a black box. The philosophy that objects
>shouldn't know how other objects are implemented. That's a nice idea, but it
>doesn't work very well in a chess program. Imagine if your chess board knew
>nothing about squares, pieces, colors, castling rights, moves, and so on. You
>could make it work, but it would be way slow with virtually no added benefit.
>
>Encapsulation on the other hand is just creating a class to act as a manager.
>The class makes sure things get initialized correctly, and that you as the
>programmer can't do nasty or stupid things easily to invalidate the private
>data. It's okay if you know that the board class uses bitboards internally, and
>even if you have member functions that return bitboards like white_pawns() or
>enemy_knights(int color). The point of encapsulation in that case is to make
>sure you can't modify the white_pawns bitboard whenever you'd like (or on
>accident).
>
>class board
>{
>private:
>public:
> // board gets initialized
> board ();
>
> // board only gets modified here
> void make_move(move m);
> void undo_move(move m);
>
> // accessor member functions
> const piece & operator [] (square s);
>
> // if you want bitboards...
> bitboard pawns (color c);
> bitboard knights (color c);
> bitboard all_pieces ();
> bitboard rotated90();
> // ...
>};
>
>All of this will get inlined so there is no overhead vs. using a struct for
>this, plus you can do error checking internally in a debug build if you want.
>This way you can still do if (board[i] == white_pawn), but you can't do if
>(board[i] = white_pawn). If you mistype, the compiler will complain about you
>modifying a const variable and your data will still be valid (piece lists will
>match up with the board). If you just use an array for the board, you just
>invalidated the board because now board[i] has a white_pawn on it, but there no
>white_pawn in the piece list for square i.
IMHO, if you have public member variables it is no longer a theoretical issue
but a personal preference.
I am not a huge fan of C++, because I think C++ attempts to take a low level
language and transform it into a high level language with a few keywords and the
STL. Having programmed in a true high level language (ML), I just don't find
C++ very attractive.
anthony
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.