Built XWin on mingw - with patches
Charles Wilson
cygwin@cwilson.fastmail.fm
Wed Nov 9 19:11:00 GMT 2011
On 11/9/2011 1:46 PM, Jon TURNEY wrote:
> On 07/11/2011 19:36, Charles Wilson wrote:
>> But this isn't true if you ever #include any of the w32api headers. Then
>> you get WIN32 defined, even on cygwin...
>
> True. I guess what I meant to say is that there isn't any compiler which
> defines both WIN32 and CYGWIN (I hope :-)).
>
> Any portable code which includes w32api headers before checking if WIN32
> is defined isn't going to be very portable :-)
But it's perfectly portable to check for __CYGWIN__ (or, for that
matter, __MINGW32__) instead of WIN32 before #including w32api headers,
because you know that the windows API will be available in those cases
as well.
The difference is, IF you do this (perfectly fine, legal, and portable)
thing:
#if defined(WIN32) || defined(__CYGWIN__)
# include <windows.h>
#endif
then you can no longer rely on
#if defined(WIN32)
...stuff that applies only for truly "native" windows (e.g.
...msvc or mingw), but not cygwin
#endif
even though both hunks above are legal and make perfect sense *in
isolation*. The problem occurs when both hunks are present in the same
translation unit -- and that's not always under your control. What if
libjpeg's header does the first hunk (it doesn't, but assume that it
does for argument's sake), and your project's headers only do the second?
You *think* you're safe in assuming that WIN32 == !__CYGWIN__,
but...#include <jpeg.h> breaks all your assumptions. But jpeg.h *did
nothing wrong*.
It's better to be explicit.
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
More information about the Cygwin-xfree
mailing list