Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: what classes all the serious C++ chess programs have?

Author: Tord Romstad

Date: 07:51:31 08/10/04

Go up one level in this thread


On August 10, 2004 at 09:52:55, Andrew Dados wrote:

>On August 10, 2004 at 08:28:53, Tord Romstad wrote:
>
>>On August 10, 2004 at 05:37:10, Gerd Isenberg wrote:
>>
>>>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.
>>
>>I understand why you want to avoid the '&' variants, but why is
>>piece.isSliding() better than isSliding(piece), and hashentry.isLowerBound()
>>better than isLowerBound(hashentry)?
>>
>
>Actually I prefere: if (hashentry.flags & LOWER_BOUND) ...
>
>Reasons:
>1) less total writing and less possible places to go wrong

I don't see how this could be true, except if we are talking about a
piece of code which is used only at one or two places in the program.

>2) faster compile,

Probably.

>3) I can rest assured that it is executed as fast as possible and create
>smallest machine code (I am never sure about different compilers treating
>template classes or inlining things or switches or...)

I am lucky, and don't need to worry about things like this.  My program
is still so weak and buggy that thinking about how to make it a tiny bit
faster would be a waste of time.

But don't all modern, optimising C compilers respect inline function
declarations?  And if they don't, or if you are afraid they don't,
wouldn't a simple preprocessor macro do the trick?

>4) it is easy to read for other people without referring to some other file

I happen to think the opposite is true.  Assume that you are looking at
the source code of a chess program for the first time, and find the
following line of code:

if(piece & 0x80) {
   ...
}

What does the (piece & 0x80) test really do?  It is not at all obvious.
In contrast, the following piece of code is very easy to understand:

if(is_sliding(piece)) {
   ...
}

The first piece of code makes it easy to see what happens on the lowest
level, but makes the purpose of the code difficult to guess.  For the
second piece of code, the opposite is the case.  When you look at some
code you don't know well, you are usually more interested in the
high-level stuff.  This is why I vastly prefer the second solution.

For the simple example above, you could opt for a hybrid solution and
do something like

if(piece & SLIDING_BIT) {
   ...
},

like Gerd suggested.  However, this isn't very practical for just slightly
more complicated operations.

>For one-time things I will just use plain code...

OK, for one-time things I often do this, too.  But one-time things are
very rare, at least in my program.

Tord



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.