Thread: RE: [GD-Windows] Strict ANSI and <windows.h>
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Jon W. <hp...@mi...> - 2002-11-03 18:14:16
|
I'm following up directly to the list because I think the question
is very valid and the reasons need to be re-inforced. Poorly designed
macros can lead to debugging nightmares. Identity of the original
requester hidden (as I'm forwarding a private e-mail).
1) The compiler will optimize out the if() for sure in release mode,
and even usually in debug mode.
2) The extra else is so that you won't be caught in a dangling else
problem. Consider:
if( something )
for( int i = 0; i < 3; ++i ) punt( i );
else
destroy_the_world();
Cheers,
/ h+
> -----Original Message-----
> Sent: Friday, November 01, 2002 9:17 PM
> To: Jon Watte
> Subject: Re: [GD-Windows] Strict ANSI and <windows.h>
>
>
> > // work-around for brain-dead MSVC for scoping problem
> > #define for if(0);else for
>
> I'm sure that there is a good reason for the else, but it isn't
> clear to me
> why that would be any different from
> #define for if(1) for
>
> Also, will the compiler optimize the extra if away, or will this
> run slower?
>
>
>
|
|
From: Grills, J. <jg...@so...> - 2002-11-03 20:34:53
|
My complaint about this technique is that I then have to disable warning
C4127: conditional expression is constant, something I'm not willing to do.
Anyone have a solution for that, but has no runtime impact?
j
-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]
Sent: Sunday, November 03, 2002 12:13 PM
To: gam...@li...
Subject: RE: [GD-Windows] Strict ANSI and <windows.h>
I'm following up directly to the list because I think the question
is very valid and the reasons need to be re-inforced. Poorly designed
macros can lead to debugging nightmares. Identity of the original
requester hidden (as I'm forwarding a private e-mail).
1) The compiler will optimize out the if() for sure in release mode,
and even usually in debug mode.
2) The extra else is so that you won't be caught in a dangling else
problem. Consider:
if( something )
for( int i = 0; i < 3; ++i ) punt( i );
else
destroy_the_world();
Cheers,
/ h+
> -----Original Message-----
> Sent: Friday, November 01, 2002 9:17 PM
> To: Jon Watte
> Subject: Re: [GD-Windows] Strict ANSI and <windows.h>
>
>
> > // work-around for brain-dead MSVC for scoping problem
> > #define for if(0);else for
>
> I'm sure that there is a good reason for the else, but it isn't
> clear to me
> why that would be any different from
> #define for if(1) for
>
> Also, will the compiler optimize the extra if away, or will this
> run slower?
>
>
>
-------------------------------------------------------
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
|
|
From: Pierre T. <p.t...@wa...> - 2002-11-03 23:06:17
|
> My complaint about this technique is that I then have to disable warning
> C4127: conditional expression is constant, something I'm not willing to
do.
> Anyone have a solution for that, but has no runtime impact?
Maybe something like this :
inline bool False(){ return false; }
#define for if(False()){} else for
You can also use a global extern variable instead of the inline function.
You can also use this in Debug builds only, if you fear it adds a "runtime
impact".
Pierre
|
|
From: Rich <leg...@xm...> - 2002-11-03 21:42:50
|
In article <9EA...@ma...>,
"Grills, Jeff" <jg...@so...> writes:
> Anyone have a solution for that, but has no runtime impact?
Its only an issue when you reuse loop variables in multiple loops
within the same scope. For that situation I'm content to declare the
loop variable in a separate statement right before the first loop that
uses it.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book <http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Kent Q. <ken...@co...> - 2002-11-04 02:29:50
|
Sunday, November 3, 2002, 4:42:47 PM, gamedevlists-windows-admin wrote:
> "Grills, Jeff" <jg...@so...> writes:
>> Anyone have a solution for that, but has no runtime impact?
> Its only an issue when you reuse loop variables in multiple loops
> within the same scope. For that situation I'm content to declare the
> loop variable in a separate statement right before the first loop that
> uses it.
Or you can simply invent a new loop variable each time. When we
realized this was going to be a problem with some code we were working
on, we just made a policy of trying to invent new variable names for
each loop. It handles the problem pretty neatly.
Kent
--
Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com
|
|
From: Grills, J. <jg...@so...> - 2002-11-03 22:33:24
|
Our project builds under Linux using g++ and Windows using MSVC. It's
fairly common for someone to check in code that builds in g++ but fails to
compile in MSVC due to this issue. But I still don't want to disable that
warning. I guess I want too much, oh well.
j
-----Original Message-----
From: Rich [mailto:leg...@xm...]
Sent: Sunday, November 03, 2002 3:43 PM
To: gam...@li...
Subject: Re: [GD-Windows] Strict ANSI and <windows.h>
In article
<9EA...@ma...>,
"Grills, Jeff" <jg...@so...> writes:
> Anyone have a solution for that, but has no runtime impact?
Its only an issue when you reuse loop variables in multiple loops
within the same scope. For that situation I'm content to declare the
loop variable in a separate statement right before the first loop that
uses it.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book <http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
-------------------------------------------------------
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
|
|
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
|
|
From: Grills, J. <jg...@so...> - 2002-11-03 23:04:24
|
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 |
|
From: Grills, J. <jg...@so...> - 2002-11-04 03:28:30
|
Excellent! This works exactly as I desire. No compile warnings, and in the
release build the disassembly doesn't show any sign of the if(False()){} at
all. Time to go throw this in the header file that's always included,
rebuild, and see how it works for the whole project.
Thank you very much.
j
-----Original Message-----
From: Pierre Terdiman [mailto:p.t...@wa...]
Sent: Sunday, November 03, 2002 5:04 PM
To: Grills, Jeff; 'Jon Watte';
gam...@li...
Subject: Re: [GD-Windows] Strict ANSI and <windows.h>
> My complaint about this technique is that I then have to disable warning
> C4127: conditional expression is constant, something I'm not willing to
do.
> Anyone have a solution for that, but has no runtime impact?
Maybe something like this :
inline bool False(){ return false; }
#define for if(False()){} else for
You can also use a global extern variable instead of the inline function.
You can also use this in Debug builds only, if you fear it adds a "runtime
impact".
Pierre
|
|
From: Grills, J. <jg...@so...> - 2002-11-04 03:51:50
|
And there was much sadness. Here's some code from STLPort, but the problem
is more generalized:
template <class _Tp, class _Alloc >
void _Deque_base<_Tp,_Alloc>::_M_create_nodes(_Tp** __nstart, _Tp**
__nfinish)
{
_Tp** __cur;
_STLP_TRY {
for (__cur = __nstart; __cur < __nfinish; ++__cur)
*__cur = _M_map_size.allocate(this->buffer_size());
}
_STLP_UNWIND(_M_destroy_nodes(__nstart, __cur));
}
Because of the if() clause, the compiler doesn't know that __cur is always
going to be initialized in debug builds, and generates a warning on the last
line in the function. So, it's not a perfect solution, but it still may be
better than not having it. I'll have fix the errors as I come across them
and decide if it is worth it or not...
j
-----Original Message-----
From: Grills, Jeff
Sent: Sunday, November 03, 2002 9:28 PM
To: 'Pierre Terdiman'; Grills, Jeff; 'Jon Watte';
gam...@li...
Subject: RE: [GD-Windows] Strict ANSI and <windows.h>
Excellent! This works exactly as I desire. No compile warnings, and in the
release build the disassembly doesn't show any sign of the if(False()){} at
all. Time to go throw this in the header file that's always included,
rebuild, and see how it works for the whole project.
Thank you very much.
j
-----Original Message-----
From: Pierre Terdiman [mailto:p.t...@wa...]
Sent: Sunday, November 03, 2002 5:04 PM
To: Grills, Jeff; 'Jon Watte';
gam...@li...
Subject: Re: [GD-Windows] Strict ANSI and <windows.h>
> My complaint about this technique is that I then have to disable warning
> C4127: conditional expression is constant, something I'm not willing to
do.
> Anyone have a solution for that, but has no runtime impact?
Maybe something like this :
inline bool False(){ return false; }
#define for if(False()){} else for
You can also use a global extern variable instead of the inline function.
You can also use this in Debug builds only, if you fear it adds a "runtime
impact".
Pierre
|
|
From: Pierre T. <p.t...@wa...> - 2002-11-05 12:15:59
|
Say I have an app that just uses "simple" inputs : - standard mouse messages - GetAsyncKeyState() for keys i.e. no special devices such as force feedback joysticks, etc (or even, no joystick at all) Is there any advantages to use DirectInput instead ? What would be the benefits in my case ? (It looks to me like it wouldn't be better, but maybe I'm misssing something) Pierre |
|
From: Pierre T. <p.t...@wa...> - 2002-11-03 18:23:54
|
Just in case.. http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MSVCFor&forum=totd&id =-1 > I'm following up directly to the list because I think the question > is very valid and the reasons need to be re-inforced. Poorly designed > macros can lead to debugging nightmares. Identity of the original > requester hidden (as I'm forwarding a private e-mail). > > 1) The compiler will optimize out the if() for sure in release mode, > and even usually in debug mode. > > 2) The extra else is so that you won't be caught in a dangling else > problem. Consider: > > if( something ) > for( int i = 0; i < 3; ++i ) punt( i ); > else > destroy_the_world(); > > Cheers, > > / h+ > > > > -----Original Message----- > > Sent: Friday, November 01, 2002 9:17 PM > > To: Jon Watte > > Subject: Re: [GD-Windows] Strict ANSI and <windows.h> > > > > > > > // work-around for brain-dead MSVC for scoping problem > > > #define for if(0);else for > > > > I'm sure that there is a good reason for the else, but it isn't > > clear to me > > why that would be any different from > > #define for if(1) for > > > > Also, will the compiler optimize the extra if away, or will this > > run slower? > > > > > > > > > ------------------------------------------------------- > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X