Author: Gerd Isenberg
Date: 02:37:10 08/10/04
Go up one level in this thread
On August 10, 2004 at 02:59:10, Andrew Dados wrote: >On August 09, 2004 at 18:26:10, Volker Böhm wrote: > >>Hi Uri, >> >>IceSpell has lot of classes for everything. It has a class for >> >>Square >>Piece >>Board >>Value >>Direction >>Position >>Evaluation (one class for every piece) >>Move-Generation (one class for every piece) >>SearchStack (holding the local information) >>Search >>Time-Control >>Move >>MoveList >>Killer >>History >>... >>(I don´t remeber everything). >> >>That had speed issues. Thats why Spike does not have those basic classes like >>Square, Piece, Value, Direcion, Move, ... >> >>Spike has got the following classes: >> >>1. A "Const" Class holding only constants that do not need memory (no const >>fields). Nearly every class is derived from the const class giving it the >>opportunity to access all relevant constant values. >> >>2. A "Const-Field-Class" holding basic lookup tables >>3. A Move-Generator-Class (only one) >>4. An Attack-Table Class >>5. A Board-Class >>6. An Evaluation-Class >>7. An Incremental-Evaluation-Class >>8. A Pawn-Hash Class >>9. A Hash Class >>10. A SEE Class >>11. A simple SEE Lookup-From-Attack-Table class >>12. A Search Class >>13. A Ponder Class >>14. An Interface Class (Supporting Winboard and UCI) >>15. A Time-Control Class (Controls that time does not exceed limit, calculates >>the "base" time and a maximal time for the current move. The base time is only >>calculated by time settings and amount of moves done) >>16. A Timefactor Class (Calculates the current time factor, the time-factor is >>only dependant of game situation and search issues (pv-change, value-change, >>...)) >> >>Maybe I forgot one or two. Some Classes are large, this is not good in a design >>point of view. But for Chess speed is most relevant. >> >>Greetings Volker > >IMO above is a typical example of bad oo programming: classes for everything. >Art for art imo. very scholar and 'proper' and sloow from design. Passing >pointers everywhere. > >Take hashtable: allocate at startup (reallocate as option) then 2 functions: >store and retrieve. Does it need its own class? NO. Ponder... Const... (why not >const.h file?). > Square and piece is just enum... why waste time to call its class is beyond my >understanding. > ><rant> I hate watching those sources where *everything* is wrapped in some >useless class - is it just me?</rant> > >-Andrew- I agree for chess it is not necessary for each generic type to make a class with abstract interfaces and to pass a this pointer and to call virtual member functions everywhere. Of course the considerations are a bit different if you plan something like "Zillions of Games". Generic inline wrapper classes for pieces, moves, hashentries etc. are IMHO nice to hide implementation and to write "ugly" code once, without any performance penalty, some examples which same assembly output: if (piece & 0x80) ... if (piece & SLIDING_BIT) ... if (isSlding(piece) ) ... if (piece.isSliding()) ... or if (hashentry.flags & 0x01) ... if (hashentry.flags & LOWER_BOUND) ... if (hashentry.isLowerBound() ) ... I prefere the latter. For hashtables a class has also some advantages - i don't mean late binding by calling virtuals but hiding the layout of hashentries and replacement scheme. So you have a header file(s) with constructor(#ofentries) and none virtual store/probe members. But the hashentry struct/class is only defined and implemented in a cpp file with the hashtable implementation. So to play around with several replacemant schemes is only one central change inside your search-object. It is possible to achive compile time polymorphism in C++ using the Barton-Nackman trick. The trick is simply to parameterize the interface with the implementation. 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.