Author: Miguel A. Ballicora
Date: 15:54:00 01/11/03
Go up one level in this thread
On January 11, 2003 at 17:29:28, Heiner Marxen wrote:
>On January 10, 2003 at 21:34:38, Robert Hyatt wrote:
>
>>On January 10, 2003 at 18:14:09, Miguel A. Ballicora wrote:
>[...]
>>>If you want portable code, use long long for both. If it is a very important
>>>variable use typedef.
>
>That often is not a good solution. Memory is not exactly for free,
>especially not so in the caches.
>Also (long long) is not exactly portable, either.
I think that you mean "using long long" is not a good solution, rather than
using typedefs. Memory is not free, I agree, that is whay I say that for an
important variable (that could be later an arrayf of them) it is better to use a
typedef. For local variables I do not think that it will really matters in most
of the cases.
If it is really needed an int16_t, int32_t, int64_t that could be defined as a
typedef. That should require a minimum maintance. My point is that it is not a
big deal that the language provide that when I could do it by myself.
However, the solution that you provide, is really *cool* because it reduces that
minimum maintaince to zero. I might steel your idea if I find myself in that
situation!
Thanks.
Miguel
>>By that logic, all that would be safe to use is "long long" which is, in itself,
>>a problem. If I only need values that fit in 32 bits, I want to be able to use
>>32 bits, and the same for 64 bits... I want to be able to say what I need,
>>and then let the compiler complain if it can't deliver that. Which will let
>>me know I have a problem, rather than the present scheme of the compiler
>>assuming something that very well could be wrong...
>
>In a direct sense you are quite right: C does not provide a portable
>solution for this. "this" being (as I understand it):
>
>I want an integral type of at least N bits. N a (compile time) constant.
>
>[ If you want types with an exact number of bits, that is even harder,
> since the platform/compiler may not have that exact size. ]
>
>But one can solve the problem at least partially.
>I've done so for Chest.
>
>It is about portability of the source code (porting binaries is a completely
>different topic), and hence I assume a target platform with a compiler.
>Additionally I assume that we can execute (run) a C program at the same
>platform where we compile it (not a cross compile).
>
>Then I figured, that I _can_ find out the exact bit size of a type like
> unsigned char
> unsigned short
> unsigned int
> unsigned long
>at _run time_.
>Well, that does not solve my problem immediately, but it helps...
>
>I wrote a small portable program, that at its run time computes the bit
>sizes that fit into the above four unsigned types. It then does four
>printf's like:
>
> printf("#define BITS_IN_UNSIGNED_CHAR %d\n", bits_in_unsigned_char);
>
>It also determines the first of these 4 types, that has bit size at least
>8/16/32, and does an appropriate printf():
>
> printf("typedef unsigned %s uint32\n", ...);
>
>This program is compiled, and run.
>Its output is stored into a file named "lcltyp.h".
>( All this can be done from the makefile )
>
>Now preparation is complete, and the rest of the program sources include
>that (locally computed, not distributed) "lcltyp.h".
>
>Now I can use any kind of stuff (typedefs, #define's) from the computed
>header, as if that would be a portable way to say it to the C compiler.
>As if C would know by itself.
>In a way I've added some introspection capabilities, which (sadly) are
>missing from C itself.
>
>[ I do not know whether C99 solves some of these issues, I refer to C90 ]
>
>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.