fuite de mémoire à l'aide (void) alloc

Question

J'ai vu une ligne similaire code flottaient dans le code Apples:

(void)[[URLRequest alloc] initializeRequestWithValues:postBody url:verifySession httpHeader:nil delegate:self]; 

URLRequest est ma propre classe personnalisée. Je n'ai pas écrit ça et je pense que le gars qui l'a attrapé vient de l'exemple d'Apple. Pour moi, cela devrait fuir et quand je l'ai testé, je suis sûr qu'il fuit 16 octets. Est-ce que cela serait? Je sais comment réparer si c'est le cas mais n'était pas sûr car il a été pris du code d'Apple.

EDIT: Le problème était avec le SDK, pas le code ci-dessus. Voir la réponse ci-dessous pour plus de détails

Answer 1

Je pensais que je pourrais mettre à jour cela car après d'autres tests et la sortie de iOS4, il a changé.

Le code ci-dessus ne fuit pas et l'empreinte mémoire de l'application revient à la normale, même après 200 itérations du code. La fuite s'est produite dans iOS3 mais était très petite, dans iOS4 il a complètement disparu à la fois dans le simulateur et l'appareil.Certains peuvent se demander pourquoi vous voudriez implémenter ce code mais cela fonctionne et a du sens quand vous traitez avec beaucoup de différents NSURLConnections dans votre code qui s'exécute simultanément.

Answer 2

Pas du tout certain de savoir ce que ce code est supposé accomplir. Cela semble briser toutes les conventions sur les méthodes d'initialisation. Quel est le point de renvoyer un pointeur vide d'une méthode d'initialisation? Le point entier d'une méthode d'initialisation est de retourner un objet. Où dans les exemples de code d'Apple avez-vous vu cela? Cela dit, je ne vois pas pourquoi cela fuirait. Comme il ne renvoie pas d'objet, il n'y a rien à divulguer à l'extérieur de la méthode. Il peut y avoir quelque chose à l'intérieur qui fuit.

Edit:

It basically does an NSURLConnection. Because we are submitting a lot of forms with a lot of different values we put it in an external class. All the delegate methods like didFailWithError: are in NSURLRequest and connectionDidFinishLoading just passes the data to its delegate. So it doesn't really need to return anything as it is done through a delegate method.

Oui, vous avez besoin de revoir cela. À l'heure actuelle, cette méthode est juste une catastrophe en attente de se produire. Si rien d'autre, tout le monde regarde ce code sera complètement confus au sujet de ce que vous faites.

Si vous n'avez pas besoin de conserver l'objet créé, déplacez son allocation et nettoyez entièrement dans une méthode. Changez le préfixe du nom de la méthode de "initialize" à quelque chose comme "setup", "configure", "acquérir" etc, donc le nom n'implique pas qu'il crée et renvoie et object.

Si vous avez besoin d'une instance one shot d'une classe particulière, utilisez une méthode de classe comme Michael Aaron Safyan suggérée (encore sans initialize dans le nom.) La méthode de classe doit initialiser en interne une instance, effectuer les opérations données à n'importe où, puis libérer l'instance. De cette façon, vous n'aurez pas à vous soucier des fuites et tous ceux qui liront votre code (y compris vous-même des mois plus tard) comprendront immédiatement ce que fait le code.

Answer 3

Oui. Ceci est une fuite, qui peut facilement être résolu en ajoutant un autorelease:

 
[[[URLRequest alloc] initializeRequestWithValues:postBody url:verifySession httpHeader:nil delegate:self] autorelease]; 

Peut-être une meilleure solution serait de créer une fonction de classe qui fait cela:

 
@interface URLRequest 
{ 
    // ... 
} 
// ... 
+ (void) requestWithValues:/* ... */ 
// ... 
@end 

Ensuite, vous pouvez simplement utiliser [ URLRequest requestWithValues:/* ... * /] sans invoquer alloc.