Author: Sune Fischer
Date: 07:46:51 08/15/04
Go up one level in this thread
On August 15, 2004 at 09:00:32, Russell Reagan wrote: >On August 15, 2004 at 06:24:16, Sune Fischer wrote: > >>In chess almost everything is about what's happening on the board, so private >>members or not you'll need heavy access. >> >>I'm not too fond of all that Get()/Set() myself. >>Does it really make the code easier to read? > >This is more readable IMO. It certainly isn't less readable. Except there are a few reasons why it's not that simple. >captured = board[to]; // overload operator [] For instance here, captured != board[to] if it's an en passent capture. >board.move_piece(from,to); >board.clear_square(from); If you use rotated bitboards you'll perhaps note that move_piece(from,to) can be optimized for captures since you don't need to set rotated bits on the to-square (except for e.p.). So lifting pieces off the board and setting them back down can be optimized if you do it all in one go. Little things like that made me realize that wrapping things in tiny methods weren't going to be easy without a cost. >captured = board[to]; // array access >board[to] = board[from]; >board[from] = empty; > >I don't really like getters/setters either, and I don't use them. > >>The only place my boards are changed is in MakeMove and UnMakeMove, so I only >>have two functions :) > >Okay, but how many places do you touch the data directly (and potentially change >it on accident)? I touch data everywhere ;) The functions that aren't supposed to change anything on the board, like the eval(), is declared const so I expect the compiler to keep me alerted here. >I still have three tiny functions, and it is enforced by the >compiler that those are the only places where modifications take place. If you >touch the data directly in one hundred functions, then you have one hundred >functions to examine if something goes wrong, not two. I think that your access functions can still be called from anywhere to do something which would corrupt, so it's not really a guarantee. >>To know how to code good computer chess one should not just read the standard >>textbooks on programming and blindly follow all their advices. >>Most of what you find in them makes the implict assumption that speed of the >>application is not critical. > >I've adopted this approach because it does work better than what I have done in >the past. In the past I did handle the raw data, and I rarely had a program >without major problems, or if I was careful, it was slow and too unflexible to >be able to speed it up later. I do what I do now because of the literally dozens >(probably over 50) of chess engines I've written from scratch. Wow, over 50? You have more experience than me then :) >Assuming >correctness is a prerequisite for success, I have seen virtually no decline in >speed (less than 1%, if any). The only thing I'm seeing is the binary size growing wildly for some reason. -S.
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.