Go to Post GDC.... Come on. Counter-clockwise? ... I believe NASCAR might file a lawsuit! - Pavan Dave [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 26-01-2005, 17:13
psquared psquared is offline
Registered User
no team
Team Role: Programmer
 
Join Date: Jan 2005
Rookie Year: 2005
Location: Chantilly
Posts: 34
psquared is an unknown quantity at this point
Weird problem with if statements

When we were doing some programming today, i wrote a good length section of code, with a few if statements thrown in there, in some of the if statements i had if(blah = blah), well i spent a good period of time trying to figure out why the code wasn't working right, and it turns out it should have been if(blah == blah), im used to java and doing it that way, but when i compiled the first time in c with if(blah = blah) it worked fine, so i thought it was fine. there is no real problem here, i just thought to let some other people know who might be running into problems and don't know why, to check that they have ==, not =, also what does = mean in an if statement?

Hope this helps anyone that needed it, and thanks for answering what does = mean if it isn't the same as ==?
  #2   Spotlight this post!  
Unread 26-01-2005, 17:26
Don Reid Don Reid is offline
Registered User
#0997
Team Role: Mentor
 
Join Date: Jan 2003
Rookie Year: 2002
Location: Corvallis, Oregon
Posts: 45
Don Reid will become famous soon enough
Re: Weird problem with if statements

Quote:
also what does = mean in an if statement?
"=" is an assignment. It also has a value, the value assigned.

So "if (a = b)..." means, Assign the value of b to a, then if that value is true (non zero) do something.

Don't feel bad. This is a common error even for experienced programers. The compilers don't complain because it is legal and sometimes done on purpose.
__________________
Don Reid
  #3   Spotlight this post!  
Unread 26-01-2005, 17:41
Dave Scheck's Avatar
Dave Scheck Dave Scheck is offline
Registered User
FRC #0111 (WildStang)
Team Role: Engineer
 
Join Date: Feb 2003
Rookie Year: 2002
Location: Arlington Heights, IL
Posts: 574
Dave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond reputeDave Scheck has a reputation beyond repute
Re: Weird problem with if statements

Quote:
Originally Posted by Don Reid
The compilers don't complain because it is legal and sometimes done on purpose.
To add on to what Don said, if you want to get the compiler to complain, you can try to get in the habit of doing the following.

if(1 == x)
{
}
instead of
if(x == 1)
{
}

With the correct comparison syntax (as written), you should see no difference when you compile, but if you were to mistakenly put a single '=' instead of a double, you would see the a syntax error. This is because it tries to assign the value of x to 1. Since you don't have permission to write to 1, you get the error.

Note that if you were to be comparing two variables, instead of a variable to a constant number, you wouldn't see the syntax error because you would be allowed to write one variable into another (in most cases).

There are some people that use this as their coding standard. I personally don't use it, but it may be something that helps you get in the habit of remembering the == when comparing.
  #4   Spotlight this post!  
Unread 26-01-2005, 19:44
Workaphobia Workaphobia is offline
Registered User
AKA: Jon
FRC #1546 (Chaos Inc.)
Team Role: Alumni
 
Join Date: Jan 2005
Rookie Year: 2005
Location: Long Island
Posts: 26
Workaphobia will become famous soon enough
Re: Weird problem with if statements

In C/C++, it is common for mutators to have return values, so that you can cascade (is that the right word?) operations. For example,
a = b = c
works because the assignment operator is right-associative. It is read in as a = (b = c), then b = c is evaluated first, and its return value is plugged into a = <that>. If the expression b = c didn't return anything, you'd have a = <void> and the compiler would generate an error.

This is why a number of C library functions return a pointer to a buffer argument. For example, strcpy (that is, string copy), which takes in a destination memory address and a source address, returns the destination pointer when it's done copying. This allows you to do something with the return instead of just sticking it by itself in a statement and putting a semicolon after it.

Combining expressions in this way can make your code a bit more difficult to read, which is probably why Java doesn't support this style that well.
  #5   Spotlight this post!  
Unread 26-01-2005, 20:23
jdong jdong is offline
Linux Nerd
AKA: John D
#0245 (Adam-Bots)
Team Role: Programmer
 
Join Date: Apr 2004
Location: Rochester, MI
Posts: 98
jdong will become famous soon enoughjdong will become famous soon enough
Re: Weird problem with if statements

Someone who's studied C++ Operator Overloading could tell you that the equals operator has similar to the following declaration:

int & operator=(int & left_hand_side, int & right_hand_side)

That is, the assignment operator returns a reference to the assigned value, allowing chaining (I think a better term) of assignments. As long as you assign a non-zero number, this statement will evaluate to TRUE. Definitely not the behavior you want....

Good for cheats, like assigning a NULL pointer within an IF statement would return FALSE, causing the block of code to be skipped. Good for experts, nightmare for beginners.
__________________
John Dong
Co-Captain, Webmaster / Programmer
Team 245 -- Rochester Adams Robotics
  #6   Spotlight this post!  
Unread 26-01-2005, 22:23
Unsung FIRST Hero
Matt Leese Matt Leese is offline
Been-In-FIRST-Too-Long
FRC #1438 (The Aztechs)
Team Role: Engineer
 
Join Date: May 2001
Rookie Year: 1998
Location: Long Beach, CA
Posts: 937
Matt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond repute
Send a message via AIM to Matt Leese
Re: Weird problem with if statements

You said you're used to working in Java but Java treats = as assignment and == as equality so I'm not sure what's going on there.

As to cascading operators (a = b = c = 1), according to the ISO C standard that will not work. However, our compiler isn't a strict C compiler. For instance, you can use C++ style comments (//comment) and it will work fine even though it's not legal C. It's not particularly important but is useful to know.

Matt
  #7   Spotlight this post!  
Unread 27-01-2005, 00:11
Workaphobia Workaphobia is offline
Registered User
AKA: Jon
FRC #1546 (Chaos Inc.)
Team Role: Alumni
 
Join Date: Jan 2005
Rookie Year: 2005
Location: Long Island
Posts: 26
Workaphobia will become famous soon enough
Re: Weird problem with if statements

That sort of makes sense. After all, jdong shows how it can be represented with operator overloads and reference returns, yet C doesn't allow reference types. Just shows how easy it is to take C++ for granted.

By the way, I remember reading somewhere that NULL (or any literal '0', since NULL is a macro) is not guaranteed to evaluate to 'false' for all implementations. This means that you may not get the result you expect when you do "if(ptr)" to test if a pointer is safe to dereference. Or maybe I have it reversed, and it's something related that isn't guaranteed... Oh well, just be careful with your if conditions.
  #8   Spotlight this post!  
Unread 27-01-2005, 13:02
Unsung FIRST Hero
Matt Leese Matt Leese is offline
Been-In-FIRST-Too-Long
FRC #1438 (The Aztechs)
Team Role: Engineer
 
Join Date: May 2001
Rookie Year: 1998
Location: Long Beach, CA
Posts: 937
Matt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond reputeMatt Leese has a reputation beyond repute
Send a message via AIM to Matt Leese
Re: Weird problem with if statements

Quote:
Originally Posted by Workaphobia
That sort of makes sense. After all, jdong shows how it can be represented with operator overloads and reference returns, yet C doesn't allow reference types. Just shows how easy it is to take C++ for granted.

By the way, I remember reading somewhere that NULL (or any literal '0', since NULL is a macro) is not guaranteed to evaluate to 'false' for all implementations. This means that you may not get the result you expect when you do "if(ptr)" to test if a pointer is safe to dereference. Or maybe I have it reversed, and it's something related that isn't guaranteed... Oh well, just be careful with your if conditions.
In C (and C++), a conditional false is any zero value. Any non-zero value is true. NULL is defined as a constant zero (the number, not the character). This means that, assuming your pointer has a value of null, if (ptr) will always work (I should note that it's not particularly good style and you should use if ( ptr == NULL) instead).

One key thing to pointers is that they do not automatically become NULL when you free the memory allocated to them. You have to set that manually. So that may be what you're referring to.

Matt
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Programming Problem: Extremely Frustrating chantilly_team Programming 19 12-02-2005 23:00
Physics Problem Venkatesh Math and Science 13 30-11-2004 20:30
Weird Output from Dashboard Port Ian W. Programming 9 06-03-2004 21:33
The problem with scouting... archiver 2001 10 23-06-2002 23:49
Major problem with chipphua motors aka Scott White Motors 18 19-03-2002 19:44


All times are GMT -5. The time now is 02:47.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi