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]

arganx wrote:

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

--
Karl Heinz Buchegger
kb******@gascad.at

[Erik Wikström]

On 2005-11-14 16:52, Karl Heinz Buchegger wrote:

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
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

[Gabriel]

Karl Heinz Buchegger wrote:

arganx wrote:

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]

Erik Wikström wrote:

On 2005-11-14 16:52, Karl Heinz Buchegger wrote:

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

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

[mlimber]

Gabriel wrote:

Karl Heinz Buchegger wrote:

arganx wrote:

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]

mlimber wrote:

...
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.

--
Best regards,
Andrey Tarasevich

[Karl Heinz Buchegger]

Andrey Tarasevich wrote:

mlimber wrote:

...
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.

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.

--
Karl Heinz Buchegger
kb******@gascad.at

[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.