Sign in to follow this  
peter_b

How do i get rid of this warning?

Recommended Posts

Im doing socket programming. After including the file <Ws2tcpip.h> for access to the function getaddrinfo(), i get the following warning: WSPiApi.h(922) : warning C4127: conditional expression is constant The code on that line is a: while (FALSE); Ok fine, but i dont want any warnings in my otherwise clean code. And i cant change in a standard header. So i #pragma it out! But!
#pragma warning(push)
#pragma warning(disable : 4727)

#include <WinSock2.h>
#include <Ws2tcpip.h>

#pragma warning(pop)

The above code does no eliminate the warning. This is the only place with the include of that file (its a precompiled stdafx header). Anyone got any clue? There are other warnings in that file that goes away with "pragma warning(disable)". But not this one. Help!

Share this post


Link to post
Share on other sites
Well, first off, the warning is 4127 yet you pragma out 4727. This could be avoided by using a for loop instead of a while loop, as explained here, but as you mentioned, you dont want to change a standard header. I would just disable the warning (using the correct number) and move on :)

Share this post


Link to post
Share on other sites
Quote:
Original post by NIm
Why is it complaining about that value being a constant? what's wrong with that?


Because the while loop's body is never or always executed when the condition is a constant (never executed in this case). If the condition is constant, you are most likely misusing the loop concept, you are supposed to use the condition to break out of the loop.

Also I don't really see the point of:
while(FALSE);
It doesn't have a body, and if it had it would never be executed.

EDIT: Wow, thanks bakery2k1, my eyes hurt now. I thought it had to do with the expansion of a macro, with is quite bad for constructing loops, but it turned out to be much worse.

[Edited by - CTar on October 22, 2006 8:42:35 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by CTar
Also I don't really see the point of:
while(FALSE);
It doesn't have a body, and if it had it would never be executed.


The OP did not completely describe the line mentioned - it is actually:
} while(FALSE);
This is the end of a do-while loop, which is being used, it appears, to allow the use of break within the loop body:
do
{
...
if(...)
break;
...
} while(FALSE);
I don't see why anyone would do this. Working to a crazy coding standard mandating a maximum number of nested if statements and "NO GOTOS!!!111"?

In later versions of the file, it is replaced with the equally insane:
for(;;)
{
...
if(...)
break;
...
break;
}

Share this post


Link to post
Share on other sites
There are times when you want a do{...} while(false);. I use it often in PHP; when you don't want to wrap your code in a function because of the hassle of declaring numerous globals, but you need a way to perform early-escape from a very long sequence of code, you have code like this...

success = false;
do {
// actions
if ( fail_condition )
break;

// actions
for ( iteration ) {
if ( fail_condition )
break 2;
// actions
}

// etc

success = true;
} while ( false );

I use this kind of construct to do validation and massive actions in PHP, like validating some mass-record alteration will work. I use this construct most often in tandem with MySQL transactions ("START", "COMMIT/ROLLBACK") to get the error safety I need.

Share this post


Link to post
Share on other sites
Quote:
Original post by Wyrframe
There are times when you want a do{...} while(false);. I use it often in PHP; when you don't want to wrap your code in a function because of the hassle of declaring numerous globals, but you need a way to perform early-escape from a very long sequence of code, you have code like this...

I have never worked with PHP, but in C++ and all other imperative languages with proper control structures I know of, it's considered very bad practice to do something like that. There aren't times you want to do it! It's just a hidden goto, so people think they are writing good code, a much better alternative would be:
f();
if( failed() )
goto failed_label;
g();
failed_label:
h();

Instead of:
do
{
f();
if( failed() )
break;
g();
}while(false);
h();

The code still contains the original design flaw, but it isn't hidden anymore. No need to hide it, you should just fix it.

Share this post


Link to post
Share on other sites
I don't think I've ever seen anyone suggest using a goto. (Shame on you[grin])
If it is unlikely to need to break out most of the time, then it is the perfect place to use an exception.
Otherwise, the code up until where it breaks to should be put in a seperate function and then a return will replace the break.

Back on topic. I actually disable warning 4244 project-wide, but it still gives me some of those warnings anyway. Anyone else get that?

Share this post


Link to post
Share on other sites
Quote:
Original post by Colin Jeanne
The code is part of a macro.


No, it isn't. It's simply part of the definition of the WspiapiLoad function, which is being defined inline in the header file.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by iMalc
If it is unlikely to need to break out most of the time, then it is the perfect place to use an exception.


Unless it's a serious error happening - no, it's not.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by iMalc
If it is unlikely to need to break out most of the time, then it is the perfect place to use an exception.


Unless it's a serious error happening - no, it's not.

Sure it is! It doesn't have to be serious, it just has to be an exceptional situation, something that wouldn't normally occur as I said.
Correct use of exceptions isn't limited to access violations. Even just a file not existing is plenty reason enough to use an exception.
I never said to use exceptions when it would need to throw most of the time.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by iMalc
Quote:
Original post by Anonymous Poster
Quote:
Original post by iMalc
If it is unlikely to need to break out most of the time, then it is the perfect place to use an exception.


Unless it's a serious error happening - no, it's not.

Sure it is! It doesn't have to be serious, it just has to be an exceptional situation, something that wouldn't normally occur as I said.
Correct use of exceptions isn't limited to access violations. Even just a file not existing is plenty reason enough to use an exception.
I never said to use exceptions when it would need to throw most of the time.


For pratctical purposes, it's best not to throw for anything that might happen during a normal run of the program. And certainly not to break out of loops, ever.

Share this post


Link to post
Share on other sites
Um... return statements, anyone? (If the code held in the macro is complicated enough to involve breaking out a for loop into surrounding context, then it probably should be its own inline function instead. We can just return from such a function; problem solved.)

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Um... return statements, anyone? (If the code held in the macro is complicated enough to involve breaking out a for loop into surrounding context, then it probably should be its own inline function instead. We can just return from such a function; problem solved.)
Yes that is definately my preferred solution too as I suggested earlier.
However I would caution the idea of making it inline.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
For pratctical purposes, it's best not to throw for anything that might happen during a normal run of the program. And certainly not to break out of loops, ever.


I disagree with the former (although I'm going to substitute "fairly typical" for the (IMHO) less well defined "normal"), although I'll agree with the later (for non erronus situations (*cough* what Zalhman says bellow your post *cough*), or situations that can't sanely, or shouldn't, be directly propigated further up the stack.

Share this post


Link to post
Share on other sites
Quote:
Original post by iMalc
Quote:
Original post by Zahlman
Um... return statements, anyone? (If the code held in the macro is complicated enough to involve breaking out a for loop into surrounding context, then it probably should be its own inline function instead. We can just return from such a function; problem solved.)
Yes that is definately my preferred solution too as I suggested earlier.
However I would caution the idea of making it inline.


This is true :) I suggested marking as inline because that's closer to the original intent of using a macro in the first place (otherwise the person writing the library would have just made a *normal* function, assuming at least marginal competence). However, that decision may have been misguided in the first place, so :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this