Re: [platform-swt-dev] GTK in CVS

[Havoc Pennington <hp@xxxxxxxxxx>]

Steve_Northover@xxxxxxx writes: 
> We could intruduce a bogus wrapper class for "int" (and watch
> performance go out the window), write our own preprocessor
> (I believe Sun forbids this) or split a stream and change all
> "int" to "long" (this is awful too, no Java IDE properly supports
> code fragments - there isn't even #ifdef - so it'd be a copy of
> the current work, yet another SWT platform).  Nothing is nice.

Is there any evidence that just using Java long would cause a
performance problem on ia32? You could use long all the time on all
platforms, I would expect that even if it impacts performance
noticeably (doubtful), time would be better spent optimizing
algorithms elsewhere than maintaining two SWT streams.

Using long breaks the memmove()-to-read-struct-fields trick, but that
trick is already broken due to bitfields and such in the C code, plus
it depends on undefined/unspecified C compiler behavior and seems a
bit intimate with the Java spec as well. The trick is also hard to
port to GTK 2, because we rearranged the structs, and is not
particularly efficient.

In GTK 2 the need to read struct fields should be quite rare, many
accessor functions were added, and just a _teeny bit_ of native glue
code when we have missing accessors would let you write legal C/Java
instead of being in the land of unportable/undefined/unspecified.

> Question:  What do other strongly typed languages do?

Some languages have a "boxed" type that represents a native pointer, I
believe. You can "box" and "unbox" native pointers from that type.

So why not use Java's "long" type for that purpose?

I am not much of a Java person, so take all this with a grain of salt.

I'm sure Jeffrey has good insights based on java-gnome.

Havoc