Author: Heiner Marxen
Date: 07:18:25 03/22/04
Go up one level in this thread
On March 20, 2004 at 16:22:57, Dieter Buerssner wrote:
>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.
I agree in all points.
>>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).
While true, once done, the resulting code will be easily adopted to yet
another 64-bit type.
Any "semi automatic" method will have to rely on some coding convention,
as far as I can see. Any practical method available in your mind?
> 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.
That occured to me, too. First, i.e., because the most important formatting
attributes (field width and left/right adjustment) work just fine with
the "%s": "%8s" or "%-8s".
Practically, I very rarely see any other flag at decimal conversions.
It appears to be a not so bad solution, IMHO.
Cheers,
Heiner
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.