Où est la fuite de mémoire ici?

Instruments me dit qu'il y a une fuite de mémoire dans ce code, mais je n'arrive pas à le trouver ... de l'aide? désolé ou la question de débutant.Où est la fuite de mémoire ici?

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath 
{ 
    int altoBufferCelda = 26; 
    Mensaje *msg = (Mensaje *)[model.mensajes objectAtIndex:indexPath.row]; 

    CGSize txtSize = [msg.texto sizeWithFont:[UIFont systemFontOfSize:17.0f] constrainedToSize:CGSizeMake(222, 222) lineBreakMode:UILineBreakModeTailTruncation]; 

    [alturasDinamicas setObject:[NSNumber numberWithFloat:(txtSize.height + altoBufferCelda)] forKey:[NSNumber numberWithInt:indexPath.row]]; 

    return txtSize.height + altoBufferCelda;  
}

Source

2009-07-03 nico

qu'est-ce que cela suppose de faire? que ce passe-t-il? quels "instruments"? Ça va aider les gens à vous aider si vous donnez plus d'informations – marcgg

marcgg, désolé pour le manque d'info. C'est un code objectif-c écrit pour l'iphone. La méthode fait partie d'un délégué utilisé pour contrôler un contrôle GUI bien connu des développeurs iphone. Et Instruments est un outil de développement utilisé pour détecter les fuites de mémoire et bien d'autres choses. – nico

@marcgg Je dirais que les développeurs de Cocoa savent que "Instruments" est l'application de profilage incluse dans les outils de développement. En ce qui concerne le but, "heightForRowAtIndexPath:" n'est-il pas assez clair? –

~~Je dirais: [NSNumber numberWithFloat]~~

Il attribuera un objet autoreleased pour vous. L'iPhone n'est pas collecté, juste la référence collectée. Et puisque vous ne libérez pas la mémoire que vous allouez avant de quitter la méthode, Instruments la signale comme une fuite.

Étant donné que ceci est actuellement accepté, je vais changer ma réponse.

Les instruments ne sont pas un édit divin. Cela pourrait être faux. Utilisez-le comme une ligne directrice de ce que vous devriez regarder, mais si vous ne trouvez honnêtement rien de mal ou de fuite avec le code, continuez tout simplement.

Source

2009-07-03 22:32:42

devrais-je ignorer cette fuite? ou essayer quelque chose de différent? Merci! – nico

Ce n'est pas correct. [NSNumber numberWithFloat:] renvoie un objet autoreleased. Vous avez raison, il n'y a pas de GC sur iPhone, mais il y a certainement des pools autorelease. Je ne vois pas de fuite dans le code réel. C'est * possible * il y a une fuite dans le framework UIKit lui-même. –

Les pools de libération automatique ne sont pas identiques à la récupération de place; si un objet autoreleased n'est pas conservé, il sera libéré à la fin de l'événement en cours, et ceci est vrai sur l'iPhone ainsi que sur OS X. La récupération de place libère des objets une fois qu'ils sont hors de portée et qu'aucun autre objet ne peut avoir accès à eux (ils sont inaccessibles). numberWithFloat renvoie un objet NSNumber qui est auto-libéré. Il n'est donc pas nécessaire de le libérer car il n'est pas conservé dans la méthode ci-dessus. –

Je ne vois aucune fuite de mémoire dans votre code. Comme le souligne Toast, les instruments ne sont pas toujours précis. C'est principalement parce que même le code de l'Apple Frameworks contient des fuites de mémoire, qui sont également signalées par Instruments. Si vous utilisez XCode 3.2, vous pouvez choisir Construire et analyser dans le menu Générer, qui analyse votre code à la recherche d'erreurs normalement non détectées par le compilateur. Cela vous montrera beaucoup de fuites de mémoire possibles résultant de l'oubli de libérer un objet.

Source

2009-11-07 15:29:38 Alfonso

Répondre

Questions connexes