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

[Grills, J. <jg...@so...>]

VS.net does indeed fix the problem.  We attempted to make the move to VS.net
a while ago, but due to issues with it, we had to abort and return to VC6.

Saying "don't do that" is not a good solution on a team of more than 10
programmers.  Verifying all projects build everywhere on all targets would
be too disruptive on programing workflow, since that would take a couple of
hours.

We've worked for 2+ years this way, it won't kill us to finish the project
like this.  I was just hoping for a magic solution.

j

-----Original Message-----
From: brian hook [mailto:bri...@py...]
Sent: Sunday, November 03, 2002 4:43 PM
To: gam...@li...
Subject: RE: [GD-Windows] Strict ANSI and <windows.h> 


> 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




-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555