windows.h breaks ObjC ?
Andrew Younger
ayounger@hampton.co.uk
Tue Nov 30 23:39:00 GMT 1999
Can you not just code fix it ala this,
#include <windows.h>
#undef interface
#include <objc/Object.h>
int main ( int argc, char *argv[] (
{
printf("hello world\n");
return 0;
}
If this works, then you could of course do it nicer, by seperating the
#undef's into a seperate file you include after <windows.h>, or you could
make a mywindows.h or equivalent which includes windows.h & the undefs, you
then of course would include this as opposed to windows.h.
This solution would probably be the best as it means that if the problem
re-occurs later on then you only have to modify one file to fix it.
> -----Original Message-----
> From: cygwin-owner@sourceware.cygnus.com
> [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of Larry
> Hall (RFK
> Partners, Inc)
> Sent: Monday, November 29, 1999 3:55 AM
> To: mlx@san.rr.com
> Cc: cygwin@sourceware.cygnus.com
> Subject: Re: windows.h breaks ObjC ?
>
>
> 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
>
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
More information about the Cygwin
mailing list