This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange behaviour with g++ 3.4.4-1


Larry Hall wrote:
At 08:45 AM 9/28/2005, you wrote:
 The correct fix, in my opinion, would be to update windef.h to not
define min and max if __cplusplus is defined, since C++ is much less
forgiving of min and max being macros in the first place (in other words,
min and max as macros only works in C).

But where does upstream windef.h live, to propose a patch to it?



Isn't it enough to offer a patch to the w32api package maintainer and let that person take this upstream?

I disagree with any proposed "fix" for this behavior. The simple fact is, the actual Microsoft headers (the ones shipped with MSVC) behave the way the current w32api package headers do.


Poorly.

But, if we "fix" w32api, then we're no longer bug-for-bug compatible with MSVC -- which means, if you want to compile software written in/for MSVC, it will behave differently when compiled using mingw or MSYS or cygwin -mno-cygwin. This would be a bad thing.

If you're using windows facilities (e.g. #including <windows.h>, then you need to understand what that means -- and code appropriately. I really don't understand why this simple question, which is answered all OVER the freakin' googlenet, has spawned such a huge thread here.

#define NOMINMAX
#include <windows.h>

It's real simple, folks.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]