Skipping if and while statements despite being true

This topic is 409 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

So i'm getting ready to wrap up a few features and start my web page design and something bad happens. My if and while statement don't work. All they needed to do was check if a condition was true and they keep skipping it. I tried "If (true), while(true), for(true)" and nothing works. I know that bool variable that they check is true. I put a break point right before the if/while statements are activated and I  know when the bool value is turned to true. I watched this variables and it said it was true. Why is this happening? Has anyone ever encountered a problem like this and how do you fix it?

Edited by LAURENT*

Share on other sites

Yes I've encountered this several times. In all cases it was caused by me messing something up.

Please post the code, otherwise we have no way of helping out.

Share on other sites

All they needed to do was check if a condition was true and they keep skipping it. I tried "If (true), while(true), for(true)" and nothing works.

You missed the obvious test of removing the test all together, although I don't think it makes any difference.

As it all makes no sense from a logic perspective, and we know a computer is a very logic-driven device, there is only one conclusion you can draw: Your hypothesis is wrong.

In other words, the "if" does get taken, it does whatever is in the "then" part, but for some reason, that has no or not enough effect.
You can try to run through it with a debugger to find the spot where it reverts your 'then' code, close inspection after a few hours doing something else also often works.

As VildNinja said already, if you want our help, we need some code lines to look at.

Share on other sites
Drop a breakpoint in your debugger, step through the code one line at a time and verify every value is what you expect.

It is extremely rare for the underlying systems to get this wrong, and it does occasionally happen on newly-released platforms and systems, but sometimes (extremely rarely) the tools will be wrong. After you have verified in your debugger that you haven't messed up the logic -- and you almost certainly have -- then step through the assembly and double check again.

Share on other sites

Also, try doing a full rebuild. Helps in a depressingly large number of cases of completely messed up behavior.

http://www.gamedev.net/topic/682628-visual-studios-2010-debugger-variable-doesnt-update/#entry5312556

I tried that, it still didn't work. From what I observed I didn't initialize a bool variable HOWEVER it always true by default for some reason. Even in the very early stages of the program's execution as soon as  this bool value is declared it is true and I didn't even set it. I'm like 'awesome bools are automatically true upon being declared". Tracking the bool variable and it behavior shows it remains consistent because I changed it to see if the variable wasn't updating for debug. I need time to prepare my code example. It ain't easy getting spot on info that help you to help me.

Share on other sites

From what I observed I didn't initialize a bool variable HOWEVER it always true by default for some reason.

bool has three states: false, true, and undefined. I believe VC++ compiler treats 0 as false, 1 as true, and anything else is undefined, however Visual Studio might treat undefined as true (because it's not 0) thus causing this confusion. I'd suggest to set it explicitly to true right before the loop - it should enter your loop.

Share on other sites

Okay..... Don't get ma

From what I observed I didn't initialize a bool variable HOWEVER it always true by default for some reason.

bool has three states: false, true, and undefined. I believe VC++ compiler treats 0 as false, 1 as true, and anything else is undefined, however Visual Studio might treat undefined as true (because it's not 0) thus causing this confusion. I'd suggest to set it explicitly to true right before the loop - it should enter your loop.

I just set it explicitly and well..... it worked. Why does this debugger keep lying to me? Why! I've read around the web a bit and came to the conclusion that I should get my program to work first then clean up everything later including initializing the uninitialized. I didn't follow it at first but later I ended up creating variables for ideas that flopped and were worthless. So I just try to get a feature to work and clean up the mess later right after it works. (sigh) my conclusions are always wrong. shit.

Share on other sites

What would the following code print? (This is compiled with VC++ 2015 in Debug mode with default project settings)

  bool f;

// watch window says:
// f	true (204)	bool
// see that "204"?
// this boolean is stored as a byte in memory, so it has 256 possible values, only two of which are true and false.
// That's 1/128th chance that the bool will even act as a boolean, regardless of not knowing its value!

if (f == false)
{
printf("first case\n"); // not printed
}
if (f == true)
{
printf("second case\n"); // not printed either.  But clearly a bool is either true or false, right?  WRONG.
}
if (f) // this is the same as (f != 0)
{
printf("third case\n");
}

Edited by Nypyren

Share on other sites

From what I observed I didn't initialize a bool variable HOWEVER it always true by default for some reason.

bool has three states: false, true, and undefined. I believe VC++ compiler treats 0 as false, 1 as true, and anything else is undefined, however Visual Studio might treat undefined as true (because it's not 0) thus causing this confusion. I'd suggest to set it explicitly to true right before the loop - it should enter your loop.

Numerically zero is false and non-zero is true regardless of type. On the die T/F is a check against zero. This is true of the language, not dependent on VS. If a bool is not defined and its memory contains a non-zero value then it will evaluate as true.

Share on other sites
On the die T/F is a check against zero

Explicit comparison to true compares to 1, thus if it was garbage value it will give unexpected results.

	bool val;
memset(&val, 5, sizeof(val)); // simulate garbage value

if (val == true) // VC++ generates cmp eax,1
cout << "true" << endl;
else if (val == false)
cout << "false" << endl;
else
cout << "undefined" << endl; // this gets printed

Edited by Zaoshi Kaba

Share on other sites

I just set it explicitly and well..... it worked. Why does this debugger keep lying to me? Why! I've read around the web a bit and came to the conclusion that I should get my program to work first then clean up everything later including initializing the uninitialized. I didn't follow it at first but later I ended up creating variables for ideas that flopped and were worthless. So I just try to get a feature to work and clean up the mess later right after it works. (sigh) my conclusions are always wrong. shit.

.

Yeah.... it's like near-zero work to initialize variables, and saves on lots of possible headaches.  Also, asserts are your friend.

(There are certain languages where uninitialized variables are more clearly defined.  Like C#.  C++ is not one of those languages.)

Share on other sites

On the die T/F is a check against zero

Explicit comparison to true compares to 1, thus if it was garbage value it will give unexpected results.

	bool val;
memset(&val, 5, sizeof(val)); // simulate garbage value

if (val == true) // VC++ generates cmp eax,1
cout << "true" << endl;
else if (val == false)
cout << "false" << endl;
else
cout << "undefined" << endl; // this gets printed


Ah. That's true, I forget that people still do (x == bool) instead of just using the value directly. Looking back up, it looks like Nypyren already covered it.

Share on other sites

bool f;

if (f == false) {
printf("first case\n"); // not printed
}
if (f == true) {
printf("second case\n"); // not printed either. But clearly a bool is either true or false, right? WRONG.
}

This is actually a fun case in C++.

Here is the relevant line from the c++ standard: "Using a bool value in ways described by this International Standard as “undefined,” such as by examining the value of an uninitialized automatic object, might cause it to behave as if it is neither true nor false".

I had quoted it earlier today for another discussion thread, but it applies here. It is one of the fun little quirks of undefined behavior. When you enter the realm of undefined behavior, all kinds of weird things can happen. The most scary of all is when it looks like it works okay, because you don't know when or if it will ever behave differently, a silent landmine in your code waiting to blow up.

Share on other sites
I didn't see your code but IIRC the last time I had such a hair-pulling situation I had mistakenly ended the if statement with a semi-colon before the curly braces. Like so:
if ( a == b );
{
//blah
}

Share on other sites

So i'm getting ready to wrap up a few features and start my web page design and something bad happens. My if and while statement don't work. All they needed to do was check if a condition was true and they keep skipping it. I tried "If (true), while(true), for(true)" and nothing works. I know that bool variable that they check is true. I put a break point right before the if/while statements are activated and I  know when the bool value is turned to true. I watched this variables and it said it was true. Why is this happening? Has anyone ever encountered a problem like this and how do you fix it?

So there are two problems here: Your code is not working the way you want it to and the debugger isn't working the way you want it to.

So let's deal with the major and actual problem first. Can you post the code so we can see it? And tell you exactly what's wrong and why?

Share on other sites

This topic is 409 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Create an account

Register a new account

• Forum Statistics

• Total Topics
628724
• Total Posts
2984404

• 25
• 11
• 10
• 16
• 14