Re: Built XWin on mingw - with patches

[Charles Wilson <cygwin@cwilson.fastmail.fm>]

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/