RE: [GD-Windows] Strict ANSI and <windows.h>
Brought to you by:
vexxed72
From: brian h. <bri...@py...> - 2002-11-03 22:43:21
|
> Our project builds under Linux using g++ and Windows using MSVC. I had assumed this problem/lack-of-compliance was resolved with VS.Net? Is that not the case or are you still using MSVC 6? > It's fairly common for someone to check in code that builds in g++ > but fails to compile in MSVC due to this issue. While I agree that a work around would be nice, the above is an indication of a discipline problem. Establishing a policy of either: A.) Verifying that, at the least, things build on all relevant target platforms before checking in or B.) Stop declaring variables inside a for(..) Doesn't seem like it should be that hard to do. I basically do what Rich recommends, which is just declare loop variables once at their first use: int i; for ( i = 0; i < x; i++ ) { } vs. for ( int i = 0; i < x; x++ ) {} I mean, switching to the latter shouldn't exactly cause people to suddenly become less efficient. It took me a day to adjust. > But I still don't want to disable that warning. I guess I want > too much, oh well. I'd be happy if <windows.h> was ANSI compliant. *sigh* The way I fixed the problem was to create a "thunking" layer that resides in one file that is dependent on <windows.h>. In this case, it's the <winsock2.h> that is the actual culprit. Since a large chunk of WinSock is compatible with BSD sockets I had hoped to avoid creating excessive/overkill abstraction layers, but that doesn't seem to be the case, because the minute any file has to #include <winsock2.h> in order to get the definition of socket(), sendto() or structs like in_addr or sockaddr, that file can no longer be compiled as strict ANSI. So now I basically I dispatch through intermediaries. Blah. But it's better than pulling out the prototypes from <winsock2.h>, de- Windowsfying them (and hoping I don't screw it up), and then using them directly. -Hook |