Strong typing for legibility and reliability is IMO for more important.
I strongly agree with this, on software engineering grounds.
> 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);
These are great examples from SWT.
If we were to do this in the GNU Classpath Java code, then the only solution I see is to use a preprocessor, and expand gpointer to an int or long as appropriate, based upon the standard pointer representation in that platform's usual ABI.
I have no idea what we will do when 128-bit machines become available. Probably by that time Sun will have added a type called "long long" or "long128", and we'll expand "gpointer" to that on the 128-bit machines.
Like Andrew, I am uncomfortable with using byte[] to represent a raw pointer. I also see Etienne's point of view that a class to encapsulate the data is pretty heavy-weight, and that only a few VMs would implement special handling for the RawPointer type. Worse, a VM that did handle it specially would not binary-compatible with one that treated it as just another class. Ick; there are no good solutions.
I hate to introduce the notion of a preprocessor. Oh well, I guess I just did.
--
Steven Augart
Jikes RVM, a free, open source, Virtual Machine: http://oss.software.ibm.com/jikesrvm
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
