Author: Gerd Isenberg
Date: 13:34:36 07/29/03
Go up one level in this thread
On July 29, 2003 at 14:46:15, Bo Persson wrote: >On July 28, 2003 at 17:34:46, Russell Reagan wrote: > >>Is there any reason to start new projects with C anymore? It seems like most (if >>not all) of the drawbacks of C++ have faded away with modern compilers. > >Of course. When we compare speed here the question is most often "Which compiler >is the fastest MSVC++ or Intel C++?". Gives a good clue, no? > > >> >>Note that I am talking about new projects, and maintaining old projects is >>obviously a good reason to still use C. > > >If you are comfortable with C++ it is a very good choice for building your >abstractions, like Piece, Move, Board, etc. > Hi Bo, A Piece class, hmm... why not? Encapsulating a scalar type without changing the size (no virtuals), hiding all the bitfrickling stuff, eg. with inline-getters like getColor(), isRookMover() etc. Currently i use an "int"-enum for pieces (including free square) and use some isRookMover(piece) from global namespace, instead of piece.isRookMover(). Move is a class already, no virtuals, only inlined functions. Same for hash-entries etc. (score(), isTrueScore()..). Assignment operator overloading in CMove, but no relationals. I use "equalMove" and "equalCoordinates" instead, because i found "==" too ambigious due to some score bits. I found it quite difficult to "design" an object model for search. Actually i use CNode, representing a position during the search, with all the BitBoard stuff for incremental update - that's fine. I derived a CSearchTree class from CNode with movegen and search. CNodes incarnation during search on the stack and chained via parent-pointer. Absolutely the wrong decision. One may introduce some "strange" bugs in search if you forgot "node." in "node.member" and you have a syntactically fine "this->member". I guess under performance considerations, it is better to use an array of nodes instead of a backward linked list on the stack. More important, the class (if any) containing the search-member function should not be derived from a board representive. Considering a multi threaded smp-version also makes sense (eg. thread-local memory for multiple search thread incarnations in one CSearchTree object, or one search thread per CSearchTree, but multiple trees with same position and shared hash). > >Right now, the focus on C++ specific groups has turned from having a complete >implementation to having the *fastest* implementation. I saw just last week that >MSVC7.1 now compiles the Boost library without a single error. That means that >these guys can now shift from looking for workarounds to looking for speedups. > > >Like I mentioned the other week, Apple has also hired Matt Austern, one of the >true C++ Gurus, to make sure that their Mac G5 using gcc will be competitive >with Intel. I am sure we will all benefit from his continued work on the >standard library, he being the original author of SGI STL/STLport and all. > >http://www.lafstern.org/matt/ and what about amd? > > >IMO there is a good future for C++! > i hope so, too ;-) A general purpose "multi paradigm"-language. High abstraction level does not contradict assembler like performance... Regards, Gerd > > >Bo Persson >bop2@telia.com
This page took 0.01 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.