Jeroen Frijters writes:
>
> > > return env->NewObject(pclass, mid, p);
> >
> > ** Bzzzt *** Please try again...
> >
> > Now that my proposal has been criticised to death on the smallest
> > nitpicks of pure ISO C portability, let me comment on the portability
> > of your code.
That wasn't my point in nitpicking. What I was attempting was showing
that to prefer one approach to another soley on the grounds of pure
ISO compatibility is probably a mistake. Every approach so far has
lacked correctness in some way.
Strong typing for legibility and reliability is IMO for more
important.
Here's a real example from SWT:
public static final synchronized native int
g_signal_handlers_unblock_matched(long /*PTR*/ instance,
int mask,
int signal_id,
int detail,
long /*PTR*/ closure,
long /*PTR*/ func,
long /*PTR*/ data);
Here it is with passing the pointers as byte arrays:
public static final synchronized native int
g_signal_handlers_unblock_matched(byte[] instance,
int mask,
int signal_id,
int detail,
byte[] closure,
byte[] func,
byte[] data);
And here it is with named opaque types:
public static final synchronized native int
g_signal_handlers_unblock_matched(gpointer instance,
int mask,
int signal_id,
int detail,
GClosurePointer closure,
gpointer func,
gpointer data);
Just for reference, here is the corresponding C declaration:
guint g_signal_handlers_unblock_matched
(gpointer instance,
GSignalMatchType mask,
guint signal_id,
GQuark detail,
GClosure *closure,
gpointer func,
gpointer data);
Andrew.
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
