[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot
|
What we did on Motif was type in the varargs combinations that we actually
used.
I think we also forced the programmer to supply the -1. SSQ?
"Boris Shingarov"
<Boris_Shingarov@xxxxxx To: platform-swt-dev@xxxxxxxxxxx
M> cc:
Sent by: Subject: Re: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot
platform-swt-dev-admin@
eclipse.org
09/18/02 04:59 PM
Please respond to
platform-swt-dev
I agree here. Silenio and I did discuss the problem with varargs a while
ago, and decided to just follow the ostrich algorithm (stick your head in
the sand and pretend there are no varargs) for now. It does not cause real
problems for SWT implementation; having a one-arg version is enough for
anything I needed so far. I agree this is world-class-ugly though.
snickell@xxxxxxxxxxxx
Sent by: To:
platform-swt-dev-admin@e platform-swt-dev@xxxxxxxxxxx
clipse.org cc:
Subject: Re:
[platform-swt-dev] GTK2 Tree: build, patch,
09/18/2002 04:22 PM and one smoking shot
Please respond to
platform-swt-dev
Boris wrote:
"Agreed in general (a lot of C code there that's WEIRD), but not in the
particular case of varargs. How is
set_value(int, boolean)
set_value(int, int)
set_value(int, String)
with the appropriate C code (full signatures), weirder than
set_value_boolean(int, boolean)
set_value_int(int, int)
set_value_string(int, String)?"
That's not really addressing the vararg issue, only the issue of
wrapping GValues (which isn't too bad, I'll admit).
The vararg problem is that the GTK function accepts a list of values of
undefined length (terminating in -1), or the same wrappered in the
va_list type (which is what a received digs out of a vararg call, but
isn't totally trivial to build). How do you want me to wrap this? Given
the constraints of the SWT APIs, only one value at a time can be changed
anyway, so IMO this is a bunch of functionally useless code since only
only column's value will be changed at once anyway in SWT (and hence
wrappering this by only accepting one value makes everything simpler).
The alternative is accepting an array to the function, unpacking the
array, and generating a va_list. This is going to be a hell of a lot
more complicated, error prone, and difficult to debug than accepting a
single argumument.
-Seth
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
