Re: INTEGER's destiny

left <[email protected]> Fri, 08 Dec 2006 19:49:39 +0100
Newsgroups gmane.comp.lang.eiffel.smalleiffel
Message-ID <[email protected]>
Guillaume Lemaître wrote:

> Paolo Redaelli a écrit :
>
>> The message of revision 7102 (Fri Mar 31 08:31:43 2006 UTC by colnet),
>> expecially regarding file smarteiffel/trunk/sys/runtime/c/base.h says:
>>
>> "No more `xxx.to_integer' or `xxx.is_integer' calls.
>> Only size-numbered calls as for example `xxx.to_integer_32'
>> or `xxx.is_integer_16'."
>>
>> Does it means that INTEGER is going to fade away and that we shall use
>> only  INTEGER_[8|16|32|64] in newly written code? Or is your plan more
>> elaborate?
>>
>> As usual thanks in advance for your attention
>>     Paolo Redaelli
>>
>>
>
> I put my comments here to all the thread, for convenience, in order 
> not to answer to a specific point of view.
>
> I'm also concerned with INTEGER bit representation. Now that I have an 
> x86_64 based CPU, I want to use preferably 64bit-long integers, as it 
> is supposed to be the fastest integer representation on this 
> architecture (the same way C coders intensively use 32bit-long 
> integers on x86 architecture). And this, I simply cannot : it would 
> require both to patch all my code, but also all the SE libraries I use.
> I tried to lurk along SE code to find where correspondence between 
> INTEGER and int is made during compilation; I have to say that it is 
> not as isolated as I supposed, maybe because noone was paying interest 
> on this very specific topic, and I can understand that.
>
> I'm ready to try to isolate this part, if some of the SE team are 
> ready to help me and explain a bit of the compiler architecture.
>
> I think Raphael proposal is good : INTEGER configuration through an 
> ACE file. Or at least at compiler installation time.
> Daniel's proposal is also very good for interfacing with legacy C code 
> or C libraries.
>
> Guillaume
>
I thought  on 64 bits plateform, the C 'int' type was still 32 bits 
sized, while 'long int' was 64 bits. Am i wrong ? So C coders who wants 
to use the largest native representation always should use the 'long 
int' type instead of the 'int' type.

<- left