Linux 64bit branch

[Jacob Carlborg]

On 2014-01-12 21:13, Jesse Phillips wrote:

> The main issue is that arr.length is size_t, I thought that that it
> would be wise not to go against the grain, but I had to back out some of
> those changes, since in reality it seems that gtk seems to expect
> count/length in int (I've squashed the commits now).

Since the Java code expects "int" in these cases, I just hope this won't 
break anything. Although, I have used size_t in the Mac OS X port, 
trying to make it 32 and 64bit compatible at once.

I'm using this philosophy when I'm porting SWT to D. In prioritizing order:

1. The public API needs to be the same on all platforms and preferably 
as the Java API.

2. The types and signatures should match the native ones. That means, if 
the native signature uses a pointer, the D code should use a pointer as 
well, even if the Java code uses int/long.

3. Try to stay as close to the original Java code as possible. This will 
make it easier to port future versions.

> To reduce casting the internals of the function utilize the D type. But
> since I was working from compiler errors it is probably just a mix.
>
>> The place where it is correct to change the type is when the SWT
>> scource code look something like this: "(int)/*64*/". That is a hint
>> to a tool SWT uses to automatically translate between 32 and 64bit.
>> These cases should always be replaced with the native type. Be it
>> either a pointer type, size_t or something else.
>
> I'll have to look into that, certainly didn't get that right.

Hmm, these might actually be the cases where it should be "int" on both 
platforms and a cast is required since it's would otherwise be "long" 
for 64bit.

You did find the other cases where I know for sure that the type should 
vary on 32 and 64bit, that is when the code looks like this:

int /*long*/

> Yes, I forgot to mention that this pass didn't concern itself with Tango.

Ok

> I'm not sure what having the return type match the type used in the
> expression has to do with anything. Unless it is floating point or some
> bit-shift manipulation.

Say I have a function like this in the Java code:

int /*long*/ foo ();

And used like this:

int /*long*/ bar = foo();

It has happened to me several times that I used "auto" when declaring 
"bar". And I changed the signature of "foo" to the correct native type. 
The only problem is that I used the wrong native type which I later 
discovered when I translated the declaration of "bar". If I had not used 
"auto" and I had use the actual correct native type when declaring "bar" 
the compiler would have a caught the type error. That's just my experience.

> Something had to change, the options are:
>
> 1. size_t or ptrdiff_t depending on the result

I think this is the most correct option.

> 2. use auto
> 3. do type conversion
>
> I chose auto because I didn't really care to identify if size_t or
> ptrdiff_t was needed (D doesn't error on mismatch if you get those
> wrong) and type conversion would then require type conversion in many
> later expressions (possibly).

Yes, see above.

-- 
/Jacob Carlborg