Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] GTK in CVS


Right, I'm wrong about the wrapping thing.  All I was getting at was we
can't cheerfully tromp through the code, changing all int's to long's
and expect everything to work.  Aside from blowing the direct platform
mapping story up, the sizes of things that are malloc'd will be wrong,
the values returned for the size of OS things can be wrong too.
We'd need a kind of "TCHAR thing" to make sure buffers were the
right size, we'd increment by it, divide by it etc.  We'd need this
anyways.  What a pain.

PHILOSOPHY:  "too slow" vs "does not work," - I'll
take "does not work" any day.  Call me crazy.

Steve



Havoc Pennington <hp@xxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

12/10/01 11:44 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:
> 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.

I don't understand that really - why would you wrap or overflow a
pointer? If you do this in C:

GtkWidget *w;
long i;

w = gtk_button_new ();
i = (long) w;
i += 57;
w = (GtkWidget*) i;

Then you have worse problems than possible overflow. ;-) i.e. these
values should never be modified, except for assignment. Arithmetic ops
are right out.

>  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.

I'm sure there's a performance difference here, but I'd be surprised
if it's enough to matter. I could be wrong.

In any case, "too slow" can't really outweigh "does not work," in my
mind.

It probably makes sense to ignore the issue until GTK 2 and java-gnome
are sorted out, and maybe until someone is actually trying an IA-64
port, since the "int" stuff is all buried underneath SWT rather than
in the API anyhow.

Havoc

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev



Back to the top