windows.h breaks ObjC ?
Larry Hall (RFK Partners, Inc)
lhall@rfk.com
Tue Nov 30 23:39:00 GMT 1999
At 06:26 PM 11/28/99 -0800, MarketLogix wrote:
>
>
>Begin forwarded message:
>
>X-Sender: lhall@pop.ma.ultranet.com
>X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
>Date: Sun, 28 Nov 1999 18:30:22 -0500
>To: mlx@san.rr.com
>From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
>Subject: Re: windows.h breaks ObjC ?
>Cc: "cygwin@sourceware.cygnus.com" <cygwin@hotpop.com>
>In-Reply-To: < 9911281643.AA07798@mlx.com >
>
>At 08:43 AM 11/28/99 -0800, you wrote:
>>Hi all,
>>
>>Just installed v1.0 and spent the whole weekend pulling my hair out.
>>
>>Oh, the general product looks pretty nice but I'm afraid that the new
>>windows headers somehow break ObjC preprocessing. I know that Cygnus
>>has never supported ObjC so, as usual, I didn't expect much.
>>
>>But it seems as though we may have hit a new low here.
>>
>>Either that or I'm just too bleary-eyed to see something obvious.
>>
>>Take this source code example, lets call it -> test.c
>>
>>#include <windows.h>
>>#include <objc/Object.h>
>>int main ( int argc, char *argv[] (
>>{
>> printf("hello world\n");
>> return 0;
>>}
>>
>>now try to compile it to object via:
>>
>>gcc -c -x objective-c test.c -o test.o
>>
>>I get the foillowing:
>>
>>Object.h:37: invalid identifier `@struct'
>>Object.h:37: parse error before `Object'
>>Object.h:38: syntax error before `{'
>>Object.h:43: method definition not in class context
>>
>>This is, of course, the first occurence of an
>>
>>@interface directive
>>
>>Now, comment out
>>//#include <windows.h>
>>
>>it compiles without a hitch.
>>
>>I built gcc-2.95.2 from gnu AND download pre-built from
>>Mumit Khan's site ALL with the same result.
>>
>>Gotta roll back to b20.1 ?
>>
>>What gives ?
>>
>>------------
>>
>>Well, I didn't send this mail right away and decided to research
>>a bit more. Here's what I found:
>>
>>basetyps.h, line #20: #define interface struct
>>
>>Oh, just brilliant - concocted by some C++ 'er no doubt !!!
>>C'mon, please tell me you're not already married to this.
>>
>>Steve B.
>>
>
>I think you'll find this is a MSism for COM. I'm sure you can work
>around
>this if necessary but if not, perhaps you want to take it up with MS...
>
>
>Larry Hall lhall@rfk.com
>RFK Partners, Inc. http://www.rfk.com
>118 Washington Street (508) 893-9779 - RFK Office
>Holliston, MA 01746 (508) 893-9889 - FAX
> (508) 560-1285 - cell phone
>
>
>Hmmmm ...
>You're the second individual to blame M$ here.
>I'm no big fan of those guys either. But I think
>this line of reasoning is flawed enough to take the
>time to slooooowly and cleeeeearly state what I
>believe to be the real underlying problem.
>
>1. I understand that M$ has its need of the "interface" label.
>
>2. This is NOT the problem.
>
>3. "interface" is distinct from "@interface".
>
>4. No problem with the global name space yet.
>
>Right ?
>
>5. Now all of a sudden in the new Cygnus windows api headers
> we get this bad boy:
>
>#define interface struct
>
>Sure, and while we're at it why not:
>
>#define constructor tulips
>
>and
>
>#define class urass
>
>What the heck nobody really codes in ObjC anymore anyway right ?
>Ah, they didn't create #undef for nothing ... RIGHT ?
>
>Yea sure, I can unhack this hack but I would hope folks could
>think a bit deeper and see this "little inconvenience" for what
>it really is.
>
>The first baby steps toward breaking Objective-C compatibility
>within Cygwin sources.
>
>Steve B.
>
Steve,
Interesting that you feel so strongly that MS is not the source of your
problem and Cygwin is. You are free to your interpretation and your
opinions and you're not bound to make use of any information you may
receive on this list. However, I fail to see the logic of your resistance
to the information I and others have provided, especially given that you
"take the time to slooooowly and cleeeeearly state what <you> believe to be
the real underlying problem." If you're going to spend the time to (re)state
your problem, its wise to consider it carefully in light of information
provided. Reviewing your statements, I find that you claim "interface" is
different from "@interface" (3), that MS needs the "interface" label (1),
and that MS's need of this label is not the cause of your problem (2).
Let's assume these are all true. Then you state that Cygwin added "#define
interface struct" to its "windows api headers" (5). OK, so if I'm supposed
to believe (1), (2), and (3), then why is (5) a problem? You said
"interface" and "@interface" are not the same things. If they aren't, then
"this bad boy" that was added is of no consequence. So both statements
can't be true and, as it turns out, for the purposes of code and cpp,
statement (3) is flawed. "interface" and "@interface" will both get the
"interface" portion mapped to "struct". Clearly, that's your problem (which
I understood quite clearly when I answered your first email message by the
way). So, this only leaves the issue of whether it makes sense to have
"#define interface struct" in the Cygwin version of the Windows header files.
You claim in your original email message that this statement is in the
Cygwin basetyps.h file. I'll take your word on that since I don't have
the Cygwin V1.0 or gcc-2.95.2 at the moment. I checked my VC++ 6.x
installation, however, and found a file called BASETYPS.H with exactly
the same #define:
BASETYPS.H:#define interface struct
Now, I'm not going to tell you that the existence of this same-named file
in Cygwin with the same #define means there is no issue with the Cygwin
version. I can't verify that things in the Cygwin version are done exactly
the same way as the MS version without having both and doing the diff
myself. However, what I can say is the #define IS the source of your
problem and its existence is NOT simply an ill-conceived whim on someone's
part. The MS file has it. That's why it was added to Cygwin. If it's
addition generates problems/bugs, no one will have a problem if you care
to track it down and submit a patch for the problem you see. If, however,
you find that there is no difference between what Cygwin has and what MS does
for VC++ in this matter, you may find you have no choice but to work-around
the issue. I can't and won't predict what the outcome will be if you care
to track your issue to its logical conclusion. I can predict that your
somewhat less-than-appreciative email persona (at least on this issue) will
not likely garner many concerned and helpful responses. Just a guess...
Anyway, good luck with your problem. Hopefully you'll find something in
what I said above helpful.
Larry
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
More information about the Cygwin
mailing list