Pourquoi ce comportement étrange se produit avec ce code? C-objectif

Question

J'ai une méthode (le code ci-dessous est une version simplifiée) qui parse petits fichiers texte:

- (void)parseFile:(NSString *)aFile 
{ 
    NSDate *date; 
    NSNumber *number; 
    NSString *desc; 

    NSString *txt = [NSString stringWithContentsOfFile:aFile encoding:NSUTF8StringEncoding error:nil]; 
    for (NSString *line in [txt componentsSeparatedByString:@"\n"]) { 
     if ([linesubstring isEqual:@"mydate"]) { 
     date = [dateFormat dateFromString:strDate]; 
     } 

     if ([linesubstring isEqual:@"mynumber"]) { 
     number = [numberFormat numberFromString:strValue]; 
     } 

     if ([linesubstring isEqual:@"mydesc"]) { 
     desc = [line substringWithRange:NSMakeRange(0, 10)]; 
     } 

     if (!date && !number && !desc) { 
     ...do something... 
     } 
    } 
} 

Le premier problème est que la variable date est rempli avec le contenu du paramètre aFile. Il suppose seulement que c'est la valeur correcte, quand le passe à travers le poing si/vérifier.

Alors pourquoi? Je pense que date pourrait être un mot réservé et échangé, mais avec le même comportement.

Le deuxième problème est avec le dernier if (avec les imbriqués). Debug le code, je peux voir que Xcode il montre que « hors de portée », mais !number échoue (Xcode pense qu'il est valide) ...

J'ai essayé d'autres combinaisons, comme [number isNotEqualTo:[NSNull null]] (celui-ci jette un EXC_BAD_ACCESS d'erreur) , sans succès.

S'il vous plaît, quelqu'un pourrait-il donner quelques conseils? Je suis novice avec le cacao/objectif-c. Je viens de java ...

TIA,

Bob

Answer 1

Il y a tout à fait quelques mauvaises choses avec le code que vous avez fourni. J'utilise la boîte de réponse, car il n'y a pas assez de place pour que ce soit un commentaire:

En ce qui concerne vos déclarations de variables:

NSDate *date; 
NSNumber *number; 
NSString *desc; 

Vous avez correctement les a déclarés, mais ne vous ai pas initialisées leur. Comme ils sont, ils pourraient pointer vers n'importe quelle poubelle aléatoire. Cela signifie que votre test à la fin de la boucle & hellip;

if (!date && !number && !desc) { 
    ...do something... 
} 

& hellip; peut en fait toujours execute parce date, number et desc peut toujours non nul (je dis peut parce qu'il est en réalité non définie si elles sont nulles ou non nul). Initialiser chacun d'eux nil si vous prévoyez de déterminer si elles sont établies ou non:

NSDate *date = nil; 
NSNumber *number = nil; 
NSString *desc = nil; 

Il est pas toujours nécessaire d'initialiser les variables (par exemple, aussi longtemps que vous écrivez avant de lire de lui, il n'est pas nécessaire de l'initialiser), cependant certaines personnes promeuvent l'idée d'initialiser toutes les variables pour empêcher ce comportement indéfini de remonter (j'initialise généralement toutes les variables même si je remplace de toute façon la valeur initialisée).

De plus, il existe une variable appelée linesubstring mais elle n'est déclarée nulle part dans le code, de même strDate, strValue ne sont déclarées nulle part non plus. Il est important de savoir comment ceux-ci sont déclarés et comment ils sont utilisés car ils peuvent de même pointer vers des ordures.