By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,503 Members | 1,628 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,503 IT Pros & Developers. It's quick & easy.

Conditional statement ALWAYS works

P: n/a
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.

Nov 22 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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
Nov 22 '05 #2

P: n/a
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
Nov 22 '05 #3

P: n/a
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
Nov 22 '05 #4

P: n/a
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.
Nov 22 '05 #5

P: n/a
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

Nov 22 '05 #6

P: n/a
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
Nov 22 '05 #7

P: n/a
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
Nov 22 '05 #8

P: n/a
>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.

Nov 22 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.