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.