RE: [GD-Windows] Strict ANSI and <windows.h>

[brian h. <bri...@py...>]

> 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