g++ -vs Java boolean

[Mark Mitchell]

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

    Mark> The semantics of overloading a single function with a
    Mark> `__java_int' argument in one case and a an `int' argument in
    Mark> the other are not clear to me, for example.

    Tom> Me neither.  But in practice you shouldn't do this.  That
    Tom> doesn't help you, I realize.

:-) 

    Tom> Another issue is installing the Java runtime header files.
    Tom> This approach would make at least one header not platform
    Tom> independent.  This is more of a pain for users to deal with.

Well, I was thinking of leaving this stuff in the front-end; just
internally representing the types like typedefs.  That would not cause
a user-visible change in the way you suggest.

    Tom> One issue is mangling.  The Java compiler mangles a (Java)
    Tom> int the same way that g++ mangles a C++ int.  If we use
    Tom> typedefs this won't always be the case.

True enough.  This seems to be the problem most difficult to overcome,
and a decent reason for the way things are.  But, in the bool case, a
typedef might be good enough, if we promise that bools will always
have eight bits, which I think we have at this point.  (They used to
be int-sized, I think.)

Another option is `jtrue' and `jfalse', which could just be
`((jboolean) true)' and `((jboolean) false)', respectively.  You could
set these up with macros in header files.

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