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

[Steve_Northover@xxxxxxx]

Can't just change things to long and cast because int's also need to wrap
and overflow and match exactly what is going on in the OS.  It's another
idea but also unsavory.  As you know, it's always fastest to use the machine
word size which is 32-bit on most machines today.  It'd be 2 pushes instead
of one.  It's another possibility.

Boxed types are included in the "bogus wrappers" option.  Basically,
everything becomes slow on both 32 and 64 bit systems. 

Wrt. the "memmove" broken thing - it won't be as long as all the types and
sizes are changed in Java.  Believe me when I say we debated long and
hard to get the current shape of the JNI wrapping.  There are tons of trade
offs. We opted for the solution that most closely matched what a C programmer
expected to see.  It's possible to map this type code, memmove's and all
directly to C, thus increasing the chance that it behaves just like equivalent
C code.

The only time we reached into GTK 1.2 stucts was when we were screwed
and couldn't get it though API.  Again, I pine for GTK 2.0.  I'd love to throw
this code in the garbage.  Unfortunately, we can't ship until you ship.

Steve

Havoc Pennington <hp@xxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 12/10/01 08:28 PM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-swt-dev] GTK in CVS

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
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev