What part of a go program written in C or C++ are you guys having
portability problems with? In dimwit there might be some assumptions,
like ints being at least 32 bits, that are not portable, and we use a
64-bit type, which is not described in the C++ standard (the C99
standard does have one). Other than that, there is a single function
that is not portable that checks whether there is input to be read,
and which we use to implement pondering. The POSIX version (these days
that means that it works on everything but Windows) is:

bool is_there_input(){
 fd_set read,write,except;
 FD_ZERO(&read);
 FD_ZERO(&write);
 FD_ZERO(&except);
 FD_SET(0,&read); // stdin

 struct timeval timeout;
 timeout.tv_sec=0;
 timeout.tv_usec=0;

 return select(1,&read,&write,&except,&timeout);
}


Other than that, I am in the process of adding multi-thread support,
for which I am using a boost library, which again can be compiled on
pretty much any modern platform. I want to do some lockless updates
(in particular for the UCT win/loss counters) which require some
assembly (less than 10 lines). But even this will be kept in a
separate module that could easily be implemented for a different
platform.

Really, now that we all use GTP and the problem of building a GUI is
out of the way, platform independence (or at least easy porting) is
quite trivial.

Álvaro.



On 6/15/07, Dave Dyer <[EMAIL PROTECTED]> wrote:

>
>So if there was any language which allows a programmer to port their code to 
be compileable and executable on a wide variety of systems it is C.
>

Java and C support two fundamentally different approaches to portability.

The approach that C supports is "chaos: deal with it".  Figure out
exactly what platform you're dealing with, compile code accordingly.
You end up with godawful kludges like "configure".  It can work, but
it requires constant maintenance to keep up with the latest twists
in the "compatible" environments.

Java's aproach is to define a virtual machine, and implement it
faithfully on each platform.  Java programs run the same everwhere;
they don't know what OS or CPU they're running on.

The same kind of approach is used to virtualize for whole platforms
- I can also run linux or windows on my intel mac.   I can run my old
PDP10 system in a window on my PC (and incidentally, MUCH faster
than it ever ran on real hardware)

Both approaches suffer from not offering access to useful (but not
modeled) aspects of the targeted platform.

_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Reply via email to