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] |
Something went wrong with my earlier attempt to send this mail. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com
- To: mitchell at codesourcery dot com
- Subject: Returned message: Re: g++ -vs Java boolean
- From: Imput-Error-Report at codesourcery dot com
- Date: Thu, 05 Aug 1999 18:42:32 -0700
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 itselfReporting-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;
- To: tromey at cygnus dot com
- Subject: Re: g++ -vs Java boolean
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: 05 Aug 1999 18:42:32 -0700
- Cc: egcs-bugs at egcs dot cygnus dot com
- Organization: CodeSourcery, LLC
- References: <m2r9lijgvh.fsf@magnus.bothner.com><19990805122304O.mitchell@codesourcery.com><87aes5279c.fsf@cygnus.com>
>>>>> "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] |