NSDate out of scope

Question

Having problems with out of scope for NSDate in an iphone app.

I have an interface defined like this:

@interface MyObject : NSoObject {
    NSMutableArray *array;
    BOOL  checkThis;
    NSDate  *nextDue;

}

Now in the implementation I have this:

-(id) init
{
    if( (self=[super init]) ) {
     checkThis = NO;
     array = [[NSMutableArray alloc] init];
     nextDue = [[NSDate date] retain];


                NSDate *testDate = [NSDate date];
    }
    return self;
}

Now, if I trace through the init, before I actually assign the variables checkThis shows as boolean. array shows as pointer 0x0 because it hasn't ben assigned. But the nextDue is showing as 'out of scope'. I don't understand why this is out of scope but the other variables aren't.

If I trace through the code until after the variables are assigned, array now shows as being correctly assigned but nextDue is still out of scope. Interestingly, the testDate variable is assigned just fine and the debugger shows this as a valid date.

Further interesting point is if I move the mouse over the testDate variable while I am debugging, it shows as an 'NSDate *' type which I would expect since that's its definition. Yet the nextDue, which to me is defined the same way is showing as a '_NSCFDate *'.

Any googling I did on the subject said that the retain is the problem, but its actually out of scope before I even try to assign the variable.

However, in another class, the same definition for NSDate work ok. It shows as nil before a value is assigned to it. Arghhh

Answer 1

I'm not sure why gdb is telling you the date is out of scope, but try remove the retain. [NSDate date] does not require a retain.

Answer 2

I've seen whacky behavior like this when I'm debugging and I have forgotten that I'm still compiling my binary in release mode.

You should also verify that you have disabled Lazy Symbol Loading in Xcode.

Answer 3

You have a few questions here.

Firstly, w**hy are some pointers to 0x0 and others to before init has completed?** Well, they've not been initialised! Their values cannot be relied upon until you have initialised them. The fact that some of them are nil (0x0) is not something that you should rely on.

Second, why is nextDue not assigned correctly? This sounds like an optimisation by the compiler. Make sure you're in debug mode (i.e., no optimisations). See what the value is at some later point after the init method has completed and returned. You might also like to change the initialisation to [[NSDate alloc] init] which removes the need to retain the value.

Third: NSDate versus _NSCFDate. Basically NSDate has a "toll-free" bridge with CFDate (the lower level, C-like API for the same thing). The compiler is apparently choosing to show the CoreFoundation version rather than the one defined in your code. It's not a big deal; I wouldn't worry about it.

Answer 4

I also posted this question in the iphone dev forum. The answer I got there seems to be correct. Basically, its just a funny thing in the debugger. Actually, not so funny considering the amount of time I spent on it. When I use NSLog to view the result of the variable, it does actually show the value correctly.

The NSDate versus _NSCFDate issue is as Stephen said, a toll-free bridge.