This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



Something went wrong with my earlier attempt to send this mail.

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


Your message was not delivered successfully.

Reason:
imput: can't open mail-aliases file: /home/mitchell/.im/Aliases, ignored.
imput: can't open host-aliases file: /home/mitchell/.hostaliases, ignored.
imput: message accepted.
imput: opening nntp session to localhost(119).
imput: nntp server localhost(119) did not respond.
imput: can't open history file: /home/mitchell/.im/putlog (No such file or directory)
imput: WARNING: nntp connection was not established.
imput: Connection refused
imput: can't open history file: /home/mitchell/.im/putlog (No such file or directory)
imput: ERROR: delivery failed.
imput: opening smtp session to localhost(25).
imput: >>> 220 adsl-206-170-148-33.dsl.snfc21.pacbell.net ESMTP Sendmail 8.8.7/8.8.7; Thu, 5 Aug 1999 18:42:32 -0700
imput: <<< EHLO localhost
imput: >>> 250-adsl-206-170-148-33.dsl.snfc21.pacbell.net Hello localhost [127.0.0.1], pleased to meet you
imput: >>> 250-EXPN
imput: >>> 250-VERB
imput: >>> 250-8BITMIME
imput: >>> 250-SIZE
imput: >>> 250-DSN
imput: >>> 250-ONEX
imput: >>> 250-ETRN
imput: >>> 250-XUSR
imput: >>> 250 HELP
imput: <<< MAIL FROM:<>
imput: >>> 250 <>... Sender ok
imput: <<< RCPT TO:<mitchell@codesourcery.com>
imput: >>> 250 <mitchell@codesourcery.com>... Recipient ok
imput: <<< DATA
imput: >>> 354 Enter mail, end with "." on a line by itself
Reporting-MTA: dns; linux1.codesourcery.com

Final-Recipient: rfc822; <tromey@cygnus.com>
Action: failure
Status: 5.1.1
Remote-MTA: localhost
Diagnostic-Code: smtp; 

Final-Recipient: rfc822; <egcs-bugs@egcs.cygnus.com>
Action: failure
Status: 5.1.1
Remote-MTA: localhost
Diagnostic-Code: smtp; 


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

    Tom>   typedef bool jboolean __attribute__ ((__mode__
    Tom> (__byte__)));

    Tom> That makes sense, since there is no way to tell that jboolean
    Tom> is a "Java" type.

Right.  One thing we could do is turn off the error.  If these things
are really typedefs, then the compilers probably going to lose track
of the types at some point anyhow; we don't really distinguish
typedefs from their equivalents in the compiler.

Basically, the clean way of doing what you want in C++ is
wrapper-classess:

  class jboolean {
    operator bool ();
    ...

    bool b;
  };

But, frankly, you'll lose optimizations this way.  And, you will
probably not get code that is linkcompatible with that provided by
gcj.  So, that route doesn't seem profitable.

I guess I'm a little stuck here.  I don't want to have weird
extensions with ill-defined semantics in G++.  That's been one of the
banes of our existence.  I understand what you're trying to do, and
agree that it make sense: writing C++ code that is link-compatible
with Java code is a good idea.  Unfortunately, we have to maintain the
C++ compiler, and this is additional complexity.  So, if we're going
to do this, we need to have good well-documented semantics, so that we
can do it right.  And, ideally, those semantics have to result in
minimal changes to the compiler, so that the implementation is not too
difficult.

Had it been up to me at the start, I would have strongly suggested
that we just make typedefs, and don't do anything special in the
compiler at all.  

Except this: mangle `extern "Java"' names differently.  What if an
extern Java name had `int' mangled as the appropriately sized Java
type, whether that was `jint', `jshort', or whatever on the platform
you're on?  (If, for example, `int' is 16-bits, then `int' would be
mangled as `jshort'.)  Furthermore, you can check that all
parameters/return types from Java functions are either Java classes,
or are of a scalar type that has a Java "equivalent".

Then, you provide a header full of typedefs.  You write ordinary C++.
It actually makes no difference whether you say `int' or `jint' in
your code, if they're the same size, but you can use `jint' for
clarity of coding.  Until the new ABI comes along, `jboolean' is just
`char', or maybe the weird typedef __mode__ thing, if that works.

How about that for a proposal?

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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]