Re: Fw: Returned message: Re: g++ -vs Java boolean

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Tom" == Tom Tromey <tromey@cygnus.com> writes:

    Tom> Java has requirements on type size.  For instance in Java an
    Tom> "int" must be 32 bits.

Understood.

    Tom> When implementing a Java native method in C++ there must be a
    Tom> single name which can be used independent of platform to
    Tom> represent this type.  Currently this is "jint".

Yup, I agree.  I'm suggesting a heaer file like this:

#if INT_HAS_32_BITS
typedef int jint;
#elif LONG_HAS_32_BITS
typedef long jint;
#elif ...
#endif 

Let's suppose that on your target, C++ ints are 16 bits and C++ longs
are 32 bits. Then, you use `jint' everywhere, just like now.  When you
write *in an extern "Java"* context:

   jint f();

or, equivalently,

   long f();

the mangler looks at `f', and says "How shall I mangle this?"  Well,
it's Java, so let's see what Java type long is equivalent to.  Hmm,
it's equivalent to a Java `int', so I'll mangle this however gcj
mangles `int'.  If you'd written `int f()' (or perhaps `jshort f()'),
then this would be mangled however `gcj' mangles `short'.  That, takes
care of mangling.

If you write `int f()', indeed you won't get an error message.
However, if you write `xyz f()' where `xyz' is some type that does not
have a Java equivalent (say a class-type not derived from
Java::Lang::Object, or whatever), then you could still get an error
message.  Similarly, for an arithmetic type with no Java equivalent.
(Like `long long', if that's 128 bits.)

Advantages:

  o Clear semantics.  This is just C++ semantics.  The typedefs are
    just ordinary user code.

  o Mangling compatibility with current practice.  Because extern 
    Java names are mangled different from ordinary C++ names, we
    retain link-compatibility.

Disadvantages:

  o Reduced error-checking on declarations.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com