Wed Mar 29 14:59:00 GMT 2000
Per Bothner <firstname.lastname@example.org> writes:
> It might make sense. I'd like to see a more specific proposal.
I'll work on one.
> Replacing JvXXX by (say) cni::XXX might be better C++ style, but is
> there enough of an advantage to make up for the work?
We would no longer be polluting the global namespace. Replacing JvXXX
within gcj wouldn't be a lot of work. For end users, we could create
a cnicompat.h that maps the JvXXX functions over to their namespace
counterparts. In that way, we'd just treat JvXXX as being deprecated.
Tom mentioned that a namespace would be useful for a precise GC, but
I'm unsure of the details on this.
> What is "the problem of conflicting CNI and JNI types"?
I'm working on code that needs to manipulate CNI and JNI types at the
same time. Both CNI and JNI stick conflicting typedefs into the
global namespace. For instance, a CNI jarray is quite different from
a JNI jarray. With a namespace, ::jarray can easily be used to refer
to the JNI type, and the CNI jarrary can be referred to as
cni::jarray, or, assuming that the cni namespace is `in use', just
> I'm not sure what is "the current name mangling".
The Jv, J, and j prefixes that are prepended to CNI routines and types
(with the exception of the primitive types).
More information about the Java