Author: Gerd Isenberg
Date: 06:23:02 08/01/04
Go up one level in this thread
<snip> >>>by making everything static, you have essentially added a namespace to a bunch >>>of "C" functions. ;-) >> >>IMHO it has some "didactical" merits to start with those "sizeless" classes >>without passing "this" to static members ;-) > >Can you say the above sentence three time in a row? :-) >I can't! What's the problem? > >In general I don't disagree with you. I only wish that if someone is going to >dive into C++, then they have the courage to jump all the way. >It is just a wish, though. Nothing more. > Yes, using abstract interfaces is of course in general a good idea. But in this case, if i want an explicit singleton object and i don't like the virtual overhead pushing "this" and doing an indirect call via vtbl. It is pragmatical to have the static memory layout inside a header file containing the namespace like class definition. Maybe it is really smarter to declare a static "interface" in a namespace only, which is implemeted inside some cpp file with module static variables (globals). <snip> >>I like to separate TimeControl (singleton) versus a statefull GameControl >>classes (probably multiple instances e.g. in a simultaneous playing program). >>My suggested TC is only about hiding the central function to get the some time >>proposals for the next move. > >Indeed. Your proposed class accomplishes, or at least points to, hiding and >encapsulating the desired functionality. I was just offering another mechanism >of doing the same thing. > Yes. >> >>GameControl is aware of moves played, time elapsed, game history and using >>associated TC _and_ search (rootNode and search-statistics) object (single move, >>safe check(s), clear recapture like PXQ, decisive winning score, (huge)fail low, >>unstable(?), best move so far is obvious or dubious...) to decide inside a >>central boolen memberfunction (shouldMove) to move or not - IMHO. > >Yes. You are correct about that. It was just an example of how the TC could be >used and it is not a good example of _where_ it should be used. > >Regards, >Hristo > In opposite to class designs for GUI-windows i found it rather "hard" to find an appropriate class design for a chess engine and game environment, considering persistence (PGN-databases), GUIs, winboard, uci, autoplayer, multithreading, mdi and multiple engines as well. I guess Steven Edwards's Symbolic approach is very instructive for such object oriented design issues. Cheers, 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.