Re: Inside or outside an if statement - what's the difference?
Re: Inside or outside an if statement - what's the difference?
- Subject: Re: Inside or outside an if statement - what's the difference?
- From: Ian Jackson <email@hidden>
- Date: Fri, 30 Sep 2005 21:28:51 +1200
Well, since I have no formal training in programming of any sort, I
have a constant fear that my style is complete rubbish, and unlike
the way anyone else programs. I would tend to agree with your odds,
and I definitely lay the blame on me. As you mentioned, this code is
a small fraction of all the code written so far, and the reason it's
not working as I expect, may lie elsewhere. My debugging to date, has
led me to believe that the problem is in the snippet I gave. I should
also mention that addSegmentToPath can be bypassed altogether and
addParticularSegmentToPath called instead. Again, defeats the points
somewhat. The code isn't my actual code and I reworded it to make it
fairly generic. there are actually a whole load of "if else"s that
follow the if (meetConditions), and there'll always be one that gets
executed. I've commented the rest out since they don't help.
When I say it doesn't work, it doesn't draw I path like I expect, as
a result of my mouse clicks. Usually the path doesn't appear till
I've finished drawing it, and then there are only 2 points in it,
where there should be many.
I usually figure these things out after grinding away at if for long
enough. Either that I'll think of a different way of doing it. If I
figure out what the problem was I'll let you know (unless it was
something embarrassingly obvious).
Thanks for your help,
Ian.
P.S. for Pontus Ilbring - what are warning flags -Wall -Wshadow?
On 30/09/2005, at 9:08 AM, James Bucanek wrote:
Ian Jackson wrote on Friday, September 30, 2005:
Hi, Thanks for the clear response. Unfortunately, I should definitely
have mentioned in the original post that I had already tried setting
break points. The meetConditions part is deliberately set
meetConditions = YES, just before the code is executed, and that's
what appears to be the case in the debugger. A break point in the
code that executes if the conditions are met
(addParticularSegmentToPath) does stop the program, so the code is
definitely being executed. It seems like, just being inside the if
statement causes some sort of problem.
I cannot imaging what. In all my years of experience with
compilers, I've never had any exhibit behavior that would make me
question the integrity of an if/else block. The only thing that
seems really odd to me is that you reassign the variable being
passed on each call to the statement:
- (NSBezierPath *)addSegmentToPath:(NSBezierPath *)aPath {
if (meetConditions) {
aPath = [self addParticularSegmentToPath:aPath];
}
return aPath;
I have no idea if this is all of your code or why you would choose
to do this. But it does beg the question of what would happen if
meetConditions was false and aPath didn't get reassigned, or if you
have a subtle syntax error in your code, of if some other call
didn't faithfully return the parameter you passed it such that
aPath suddently points to another object, or nothing at all. This
seems like a programming convention that's ripe for introducing bugs.
My only suggestion is to keep debugging. Walk through the each step
of your program as it calls addParticularSegmentToPath, and the
step through it when meetConditions is false and try to find out
what's different.
And you never really explain what "doesn't work" means, so we can
only offer broad suggestions on how to track it down. If I were a
betting man, I'd lay 10,000,000:1 odds that you've got a subtle
programming bug somewhere against the if statement of the compiler
being broken.
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden