NSDate hors de portée

Question

Ayant des problèmes avec hors de portée pour NSDate dans une application iphone.

J'ai une interface définie comme ceci:

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

}

dans la mise en œuvre, j'ai 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 attribuer les variables réellement checkThis montre que booléen. tableau montre que le pointeur 0x0 parce qu'il n'a pas ben affecté. Mais la nextDue montre comme « hors champ ». Je ne comprends pas pourquoi il en est hors de portée, mais les autres variables ne sont pas.

Si je trace dans le code jusqu'à ce que les variables sont assignées, un tableau montre maintenant comme étant correctement attribué, mais nextDue est toujours hors de portée. Fait intéressant, la variable TestDate est affecté très bien et le débogueur montre cela comme une date valide.

De plus intéressant est de savoir si je déplace la souris sur la variable TestDate alors que je suis le débogage, il montre que le type d'un «NSDate * que j'attendre puisque c'est sa définition. Pourtant, le nextDue, qui me est défini de la même façon montre comme un «_NSCFDate *.

Tout googling je l'ai fait sur le sujet a déclaré que le retenir est le problème, mais son fait hors de portée avant d'essayer même d'assigner la variable.

Toutefois, dans une autre classe, la même définition pour NSDate fonctionne bien. Il montre que nul avant qu'une valeur est affectée. Arghhh

Answer 1

J'ai également signalé cette question dans le forum iphone dev. La réponse que je suis arrivé semble qu'il y ait raison. En fait, c'est juste une drôle de chose dans le débogueur. En fait, pas si drôle compte tenu de la quantité de temps passé là-dessus. Lorsque j'utilise NSLog pour afficher le résultat de la variable, il ne montre en fait correctement la valeur.

La question NSDate contre _NSCFDate est comme Stephen dit, un pont sans frais.

Answer 2

Je ne sais pas pourquoi gdb vous dit la date est hors de portée, mais essayez de retirer le conserver. [Date NSDate] ne nécessite pas retain.

Answer 3

Je l'ai vu le comportement délirant comme ça quand je suis débogage et je l'ai oublié que je compiler toujours mon binaire en mode de libération.

Vous devez également vérifier que vous avez désactivé Symbole Lazy Chargement en Xcode.

Answer 4

Vous avez quelques questions.

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

En second lieu, pourquoi nextDue pas attribué correctement? Cela ressemble à une optimisation par le compilateur. Assurez-vous que vous êtes en mode débogage (à savoir pas Optimisations). Voir ce que la valeur est à un moment plus tard après la méthode de init a rempli et retourné. Vous aimerez aussi changer l'initialisation à [[NSDate alloc] init] qui élimine la nécessité de conserver la valeur.

Troisième: NSDate par rapport _NSCFDate . Fondamentalement NSDate a un pont « sans frais » avec CFDate (niveau inférieur, API C comme pour la même chose). Le compilateur choisit apparemment pour montrer la version CoreFoundation plutôt que celui défini dans votre code. Ce n'est pas grave; Je ne vous inquiétez pas.