Author: Gerd Isenberg
Date: 08:51:18 01/07/06
Go up one level in this thread
On January 07, 2006 at 01:59:53, Tony Werten wrote: >On January 06, 2006 at 14:52:52, Gerd Isenberg wrote: > >>On January 06, 2006 at 13:41:06, Tony Werten wrote: >> >>>On January 06, 2006 at 11:54:27, Gerd Isenberg wrote: >>> >>>>>>But doesn't hiding the implementation for this scalar wrapper class - without >>>>>>any virtuals - also imply that it don't cares whether a public interface is used >>>>>>internally but also privat members? >>>>> >>>>>Sorry Gerd, I don't quite understand your question. >>>>>Can you try to rephrase it? >>>>> >>>>>Best, >>>>>Alex >>>> >>>>If isAdjacent is a const member or friend, it has read access to >>>>private/proteceted members - but is not forced to do so - it may also use the >>>>public interface only. If so, should that be a reason to make the function not >>>>member or friend? >>>> >>>>Making a function a member of a class or not - should imho not only depend on >>>>its access rights, but also on the semantic and logical relations of the >>>>function. >>>> >>>>I mean with some point and rectangle classes - i found it so far somehow natural >>>>or at least familiar to have the boolean isPointInRect as member of a rectangle. >>> >>>Hmm, it seems I have different thoughts. I agree with the above. isPointInRect >>>could be a member of CRectangle, but not of CPoint. >>> >>>By the same reasoning, a CSquare should not have an IsAdjacent, but a CBoard >>>(containing CSquares) should. >> >>Now it becomes interesting ;-) >> >>Assuming CSquare already "knows" how to move on the board as suggested by Alex, >>why should a container of squares be exclusive owner of the isAdjacent property? > >Because it's the CBoard that decides wether 2 squares are adjacent, not the >squares itself. > >When you design a new board (ie round or something), the squares stay the same, >you just override IsAdjacent and other stuff (goUp,goDown etc) in CBoard. > >I disagree with having a square know how to move. Squares don't move. Squares >can have pieces on them that know how to move. > >When playing a chessvariant with new pieces, just derive the new piece from >CPiece and override its moving. > >> >>CBoard might also contain no CSquares at all, but bitboards!? > >Implementation details :) > >Every board contains squares. It also might use some internal representation for >it that is different. > >Disagreement again btw. Bitboards should be implemented in the representaion of >the pieces, not the squares. IMO Ok - after some confusion about CSquare and CBoard... CSquare, as discussed here as int-wrapper, is used to index the board. Thus CSquare does not contain piece-codes, neither is CBoard a container of CSquares with this semantic. Therefor i would better call it CSquareIndex or CSquareCoordinate rather than CSquare. Having more dedicated types or wrapped int- or enum-classes for SquaresIndex, Pieces etc. and appropriate function prototypes the compiler is aware of invalid type errors. Since one can't pass accidently a piece code to a function which requires a square index - which is syntactically possible with all as ints. Assuming a board with ranks and files, should CSquareCoordinate as an int-wrapper "know" all coordinates? Should it hide it's binary representation (8*8, 8*10, 0x88) and only allow symbolic, enumarated values as publics inside the scope of the class (A1..H8 (or J9) and probably INVALID) as immediate operands? If yes, it should also hide the arithmetic operations how to increment or decrement square indices rank- and filewise. Should therefor a move-generator delegate it's piece specific move productions rules to the CSquareCoordinate class? May a "perfect" oo-design for chess-engines should allow changing of the internal board representation "easily"? I fear performance wise it still too expensive. > >Wether this all can be done efficient might be something completely different. > >> >>What i know for sure - my previous (still working) design decision, to derivate >>CSearchTree from CNode to implicitly get a root-node for the search was a very >>bad idea (don't derivate from concrete classes!). > >Deriving seems a but too much. Why not let CSearchTree just contain CNodes (or >CBoards/CPositions) fe a startpointNode and a currentPositionNode. Yes - currently i have a CSearchTree object including this implicite root-node. Further nodes are locals on the stack. The problem was, while writing code, not always fully aware in which class namespace i was (CNode or CSearchTree) - thus confused node.foo() with [this.]foo() which was syntactically ok. I introduced some bugs, because i took properties of the root-node instead of the current node ;-( Gerd
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.