[computer-go] Orego's Adventures in C++

[Eric Boesch]

I second Darren's comments, with the elaboration that you have to #include 
<stdint.h> before you can use uint32_t etc.

Also, I got the impression you might be looking to essentially implement 
bitset<81> or bitset<361> by hand. But they're pretty well optimized to 
begin with; after all, the designers of standard headers can, and generally 
do, tweak them so their implementations are really fast, since the headers 
are customized for your machine.  (I don't recommend vector<bool> as an 
alternative to bitset<> -- it lacks convenient operations liike a & b, and 
it requires a single memory allocation each time you create one, so on 
modern machines, there goes hundreds of CPU cycles down the drain... Echoing 
others' comments, I once doubled the speed of my program just by adding a 
single reserve() call.)

I found the nonstandard (but supported by stl and g++) bitset methods 
_Find_next and _Find_first to be useful, because they perform common tasks 
with a speed that application writers cannot match while still writing 
portable code based on bitsets. Actually, I ended up using macros to 
encapsulate the semantics "for each bit in this bitset that is ON, do 
<foo>"; many people hate macros, but in that one case they made my code more 
legible, shorter, and easier to maintain (since the nonstandard calls 
mentioned above appear only in the macro definitions, where they can be 
swapped out if I ever have to do that).

As for the

// header foo.h
#ifndef _foo_h
#define _foo_h
... code goes here...
#endif

trick, it appears constantly in C/C++, so you are unlikely to find a C/C++ 
preprocessor so broken that it could ever see the "code goes here" part 
twice while compiling the same source file. There are many other reasons why 
duplicate definition warnings may arise, though.

>From: Darren Cook <darren at dcook.org>
>Reply-To: computer-go <computer-go at computer-go.org>
>To: computer-go at computer-go.org
>Subject: Re: [computer-go] Orego's Adventures in C++
>Date: Tue, 08 Aug 2006 08:34:25 +0900
>
>Hi Peter,
>I'm keen to see how you get on, both in terms of effort and in terms of
>any performance gain you get.
>
> > ours. That said, if anyone has algorithmic or idiomatic suggestions,
> > we'd be happy to hear them. Our C++ probably has a thick Java accent
> > right now, but hopefully that will change in the next couple of weeks.
>
>The size-specific types have _t appended. E.g.  int8_t, uint32_t,
>uint64_t, etc.
>
>I'd suggest wrapping your code in a namespace. I also prefer to not do
>"using namespace std" and instead put a std:: prefix when calling
>standard library functions. It makes it easier for me to see at a glance
>the external libraries I am using.
>
>You can put everything in the .h file, and have no .cpp file. This is
>considered more modern C++ style, a la Boost (and is also more java
>like). Sometimes you have no choice of course, and you need a cpp file.
>Using all .h files can also increase compilation times (as changing a
>function body can cause more recompilation).
>
>I have this in my code:
>   typedef unsigned short int BIX;
>
>(where BIX stands for "Board Index"). This not only makes the code less
>verbose it also makes it easy to try other data sizes. E.g. my code
>actually looks like this:
>
>#ifdef use_BIX_short
>typedef unsigned short BIX;
>#else
>typedef unsigned int BIX;
>#endif
>
>Using an int was 5% quicker last time I tested, so is the default.
>
>Darren
>_______________________________________________
>computer-go mailing list
>computer-go at computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/