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: James Bucanek <email@hidden>
- Date: Thu, 29 Sep 2005 14:08:52 -0700
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