Linux 64bit branch
Jesse.K.Phillips+D at gmail.com
Sun Jan 12 12:13:33 PST 2014
On Sunday, 12 January 2014 at 11:42:30 UTC, Jacob Carlborg wrote:
> * Most changes seems to be related to changing "int" to
> "size_t" or "ptrdiff_t". "int" was used because that's what the
> Java API uses. Java doesn't even have unsigned types. Is the
> changes really necessary? Does it require a lot of casts
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
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
I'll have to look into that, certainly didn't get that right.
> * Currently DWT is compatible with both D1 and D2. Could you
> please use "to!(T)(args)" instead and import
> "tango.util.Convert" when Tango is used to make it compatible
> with D1 as well. I do intend to drop the support for D1 at some
> point, either when I merge in DWT-Cocoa or when there is a
> significant large change making it not practical to do the
> change both for D1 and D2. Anyway, I want to drop the support
> in a controlled way, making a D1 branch, make an announcement
> and so on. I don't think this is a significant large change to
> break the D1 support. It's easy to make it compatible with both
> D1 and D2.
Yes, I forgot to mention that this pass didn't concern itself
> * I see that you have used "auto". I prefer we try to avoid
> using "auto" at all. My experience with using "auto" in DWT is
> that it's easier to make a mistake when porting. When not using
> "auto" both the return type of a function and in the expression
> where it's used need to have the correct type. Also, "auto"
> doesn't exist in Java and we want to stay as close to the Java
> source code to make it easier to merge future versions.
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.
Something had to change, the options are:
1. size_t or ptrdiff_t depending on the result
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).
> Ok, I see. Have you verified that you have all the necessary
> libraries installed? They're listed here:
Not yet, will be something to look into.
More information about the Digitalmars-d-dwt