Author: Dieter Buerssner
Date: 13:22:57 03/20/04
Go up one level in this thread
On March 20, 2004 at 15:53:42, Heiner Marxen wrote:
>On March 20, 2004 at 13:09:53, Dieter Buerssner wrote:
>
>>On March 20, 2004 at 10:48:04, Heiner Marxen wrote:
>>
>>>On March 19, 2004 at 16:43:24, Pat King wrote:
>>>
>>>>unsigned long long I = (unsigned long long)1 << 35; // I'm guessing this is more
>>>>//portable than '1LLU'?
>>>
>>>You should make a typedef for your 64-bit type, like
>>>
>>>typedef unsigned long long U64_t;
>>>
>>>U64_t I = (U64_t)1 << 35;
>>
>>I am not 100% sure, but I think, U64_t may be a reserved name in POSIX/XOPEN
>>(and all names ending with _t). The glibc manual writes under reserved names:
>>
>>"Names that end with _t are reserved for additional type names."
>
>That comes as a surprise to me. As far as I've read the C90 standard,
>there does not appear such a reserved suffix rule.
You are correct. Such a rule does not appear in the ISO Standards for C (C90 or
C99). But practically, it is impossible to write a chess engine only following
those standards. The main reasons are: you want to have a method to check for
pending input (typically select() under Unix, alternative will be to use
multithreading, which again will use facilities not defined in ISO C) and you
will probably want to have a method for sub second times (say gettimeofday). Now
you will include some POSIX headers, and as far as I understand, those headers
are free to use any typedefs some_type xxx_t; to their liking. So, one should
try to keep away of those names.
>May be it is an
>addition by the glibc, or a POSIX/XOPEN thing as you suggest... dunno.
I think, the later (primarily).
>>>Yes, that way (with the cast) it is more portable than the suffix with LL,
>>>since you only need to get the typedef right.
>>>Another portability problem is the printf format for such values.
>>
>>Indeed. It is easy to change one typedef, but not easy to change many printf
>>format specifiers (especially, when one didn't think of it in advance). It is
>>also the reason, that I was too lazy until now, to change all my counters (which
>>are typically unsigned long) to avoid overflow (node counters overflow in the
>>order of magnitude of one hour on a typical modern computer). If the printf were
>>few, it wouldn't be a large problem. But I have them in masses (especially in
>>debugging code).
>
>Yes, exactly. I've had the exact same problem, and not yet found a really
>satisfactory solution. One idea here is to write a conversion function
>
> const char* counter2str(COUNTER c);
>
>returning a pointer into a circular collection of sufficiently large
>string buffers, allocated statically. If I use (say) 16 such buffers,
>I can use up to 16 such conversion result simultaneously in one printf,
>while avoiding all problems that appear with dynamic allocation.
>
> printf("Tried %s, hits=%s\n", counter2str(tried), counter2str(hits));
>
>With a sufficiently short name for the conversion function this might
>work ok. When the typedef changes, we only have to adjust the conversion
>function body, but not any uses of it.
I thought of the same thing. It will still need a lot of changes in the source
(that cannot be done in a semi autmatic way). Also, practically, the
couter2str() function will need more arguments. printf("%8d", ...); etc. There
are many "flags" for the printf conversions (align to the left, add zeroes in
the front, etc.). So, having a function for counter2str does not seem to buy
much IMHO.
>
>>Definetly an advantage of C++ with its typesafe printing facilities.
>
>Yes, that is true. One of the few reasons that appear to really favor C++
>over C for something like a chess program. Yet, I stick with C. :-O
Same here.
Cheers,
Dieter
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.