2009-06-11 8 views
0

Problèmes avec NSDate hors de portée dans une application iphone.NSDate hors de portée

J'ai une interface définie comme ceci:

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

} 

Maintenant, dans la mise en œuvre je ceci:

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


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

Maintenant, si je trace à travers l'init, avant que je cède effectivement les variables checkThis montre comme booléen. tableau affiche comme pointeur 0x0 car il n'a pas été affecté. Mais le nextDue montre comme 'hors de portée'. Je ne comprends pas pourquoi c'est hors de portée mais les autres variables ne le sont pas.

Si je parcours le code jusqu'à ce que les variables soient affectées, le tableau indique maintenant qu'il est correctement affecté mais que nextDue est toujours hors de portée. Il est intéressant de noter que la variable testDate est correctement attribuée et que le débogueur indique cette date comme valide. Un autre point intéressant est que si je déplace la souris sur la variable testDate pendant que je débogue, elle apparaît comme un type 'NSDate *' auquel je m'attendais puisque c'est sa définition. Pourtant, le nextDue, qui pour moi est défini de la même manière, apparaît comme un '_NSCFDate *'. Tout ce que j'ai fait sur Google sur le sujet dit que la retenue est le problème, mais c'est vraiment hors de portée avant même que j'essaie d'assigner la variable.

Toutefois, dans une autre classe, la même définition de NSDate fonctionne correctement. Il apparaît comme nul avant qu'une valeur lui soit affectée. Arghhh

Répondre

1

J'ai aussi posté cette question dans le forum ip dev. La réponse que j'ai reçue là-bas semble être correcte. Fondamentalement, c'est juste une chose amusante dans le débogueur. En fait, pas si drôle compte tenu du temps que j'ai passé dessus. Lorsque j'utilise NSLog pour afficher le résultat de la variable, il affiche réellement la valeur correctement.

Le problème NSDate contre _NSCFDate est, comme l'a dit Stephen, un pont sans frais.

0

Je ne sais pas pourquoi gdb vous dit que la date est hors de portée, mais essayez de supprimer la retenue. [Date NSDate] ne nécessite pas de conservation.

0

J'ai vu un comportement bizarre comme ça quand je débogue et j'ai oublié que je suis encore en train de compiler mon binaire en mode release.

Vous devez également vérifier que vous avez désactivé le chargement de symboles paresseux dans Xcode.

0

Vous avez quelques questions ici.

Tout d'abord, w hy sont quelques pointeurs sur 0x0 et d'autres à avant init a terminé? Eh bien, ils n'ont pas été initialisés! Leurs valeurs ne peuvent pas être invoquées tant que vous ne les avez pas initialisées. Le fait que certains d'entre eux sont nil (0x0) n'est pas quelque chose que vous devriez compter.

Deuxièmement, pourquoi nextDue n'est pas affecté correctement? Cela ressemble à une optimisation par le compilateur. Assurez-vous que vous êtes en mode débogage (c'est-à-dire, aucune optimisation). Voir ce que la valeur est à un point ultérieur après que la méthode init a été complétée et renvoyée. Vous pouvez également modifier l'initialisation en [[NSDate alloc] init], ce qui supprime le besoin de conserver la valeur.

Troisième: NSDate par rapport à _NSCFDate. Fondamentalement NSDate a un pont "sans frais" avec CFDate (le niveau inférieur, API de type C pour la même chose). Le compilateur choisit apparemment d'afficher la version CoreFoundation plutôt que celle définie dans votre code. Ce n'est pas grave; Je ne m'inquiéterais pas pour ça.

Questions connexes