Conditional statement ALWAYS works

[arganx]

The conditional statement "if(j.... always executes regardless of what
you enter.

BOOL CALLBACK EnumWindowsProc(HWND hwnd,LPARAM lParam)
{
char buffer[256]="";
GetWindowText(hwnd,buffer,256);
if(!strcmp(buffer,""))
{
return TRUE;
}
printf("%d. %s\n",i,buffer);

cout << "is this it?: " << flush;
int j = 0;
cin >> j;
cout << endl;
if (j=1) cout << hwnd << buffer << endl; //This always excecutes

//regardless of input
i++;
return TRUE;
}

Futher, if you change it to "int j = 1", it will never execute -
regardless of imput.

Any help would be appreciated.

 

[Karl Heinz Buchegger]

The conditional statement "if(j.... always executes regardless of what
you enter.

BOOL CALLBACK EnumWindowsProc(HWND hwnd,LPARAM lParam)
{
char buffer[256]="";
GetWindowText(hwnd,buffer,256);
if(!strcmp(buffer,""))
{
return TRUE;
}
printf("%d. %s\n",i,buffer);

cout << "is this it?: " << flush;
int j = 0;
cin >> j;
cout << endl;
if (j=1) cout << hwnd << buffer << endl; //This always excecutes

This is not a condition but an assignment

if( j == 1 )

Now, *this* is a condition

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

This is not a condition but an assignment

if( j == 1 )

Now, *this* is a condition

Out of curiosity, can an assignment return false? And if so under which
conditions?

Erik Wikström

 

[Gabriel]

The conditional statement "if(j.... always executes regardless of what
you enter.

BOOL CALLBACK EnumWindowsProc(HWND hwnd,LPARAM lParam)
{
char buffer[256]="";
GetWindowText(hwnd,buffer,256);
if(!strcmp(buffer,""))
{
return TRUE;
}
printf("%d. %s\n",i,buffer);

cout << "is this it?: " << flush;
int j = 0;
cin >> j;
cout << endl;
if (j=1) cout << hwnd << buffer << endl; //This always excecutes

This is not a condition but an assignment

if( j == 1 )

Now, *this* is a condition

I would like to add:
If you didn't get a compiler warning for this, you should compiler with
a higher warning level. The compiler can help help you with a lot of
mistakes like this one.

Gabriel

 

[Gabriel]

Out of curiosity, can an assignment return false? And if so under which
conditions?

Erik Wikström

The assignment returns the content of the variable assigned to.
Thus
if (j=0)
is false and would not execute.

 

[mlimber]

The conditional statement "if(j.... always executes regardless of what
you enter.

BOOL CALLBACK EnumWindowsProc(HWND hwnd,LPARAM lParam)
{
char buffer[256]="";
GetWindowText(hwnd,buffer,256);
if(!strcmp(buffer,""))
{
return TRUE;
}
printf("%d. %s\n",i,buffer);

cout << "is this it?: " << flush;
int j = 0;
cin >> j;
cout << endl;
if (j=1) cout << hwnd << buffer << endl; //This always excecutes

This is not a condition but an assignment

if( j == 1 )

Now, *this* is a condition

I would like to add:
If you didn't get a compiler warning for this, you should compiler with
a higher warning level. The compiler can help help you with a lot of
mistakes like this one.

Gabriel

Agreed. In fact, I'd suggest you should probably always compile on the
maximum warning level and alter the code (or manually disable specific
warnings) to get a warning-less build.

Also, programming style can help with cases like yours if you train
yourself to put constants first in equality tests:

if( 1 == j )

instead of

if( j == 1 )

Then there can be no confusion and compiler will always complain with
an error if you forget the second equal sign.

Cheers! --M

 

[Andrey Tarasevich]

...
Also, programming style can help with cases like yours if you train
yourself to put constants first in equality tests:

if( 1 == j )

instead of

if( j == 1 )

Then there can be no confusion and compiler will always complain with
an error if you forget the second equal sign.
...

In my personal opinion (and I'm not alone in this, according to many
discussions on that subject I saw) the negative impact this habit has on
the readability of the code far outweigh the planned benefits. I, for
example, always use the "natural" order of operands in comparison

if (j == 1)

and I've never had any problems of the above nature.

The reversed notation '(1 == j)' is just one of those things that seem
to make sense in theory but have very little or no value in practice.

 

[Karl Heinz Buchegger]

In my personal opinion (and I'm not alone in this, according to many
discussions on that subject I saw) the negative impact this habit has on
the readability of the code far outweigh the planned benefits. I, for
example, always use the "natural" order of operands in comparison

if (j == 1)

and I've never had any problems of the above nature.

Same here.

Those mistakes stopped long ago, when I changed my coding style from
if(j=1)
to
if( j == 1 )

Just adding whitespace (and of course getting more practice) did the trick.

 

[carlmuller]

In fact, I'd suggest you should probably always compile on the maximum warning level

Usually that is very good advice, except with certain compilers (e.g.
Microsoft Visual Studio) that proceed to emit vast amounts of warnings
about the vendor supplied header files that would swamp any warnings
about your own code. So the next level down might be more helpful.