Il me semble : une "convenient method" comme scannerWithString: crée le scanner en autorelease. Par contre, en forçant le nombre de boucles dans le test, je tombe sur un manque de mémoire qui est sans doute dû au fait que la libération de la mémoire des objets en autorelease sont réalisés en lazy-mode. Cela confirme le post de Bru.
En ce qui concerne l'objet NSScanner, je ne m'inquiète pas. Je m'inquiète surtout pour l'objet placé grâce à la référence : ¤t dans la méthode scanUpToCharactersFromSet:intoString: est-ce que le résultat stocké dans la référence reçoit un message autorelease ?
Ensuite, ce truc : return [[array retain] autorelease]; sert à rien
Tout à fait d'accord. J'avais été surpris de le trouver dans le script Apple "Place Accessor Defs On Clipboard" (menu des scripts de XCode), alors un peu de provoque ...
Dans le cas d'un accesseur, ça peut servir à quelque chose.
[tt]id obj = [rec myVar]; // (1) en supposant que _myVar ait un retainCount de 1
// beaucoup de code et si possible via des appels de méthodes pour compliquer le debugging [rec setMyVar:newObj]; // (2)
// encore du code
[obj doSomething]; // crash si pas de retain/autorelease, l'objet désigné par obj a été libéré en (2), ou bien il aurait fallu faire un retain en (1)[/tt]
Ce n'est donc pas si innocent, même si ce genre de cas de figure est plutôt rare (jamais rencontré perso).
Je m'inquiète surtout pour l'objet placé grâce à la référence : ¤t dans la méthode scanUpToCharactersFromSet:intoString: est-ce que le résultat stocké dans la référence reçoit un message autorelease ?
Oh ben ce serait mal foutu, et indiqué dans la doc qu'il reste à la charge du receveur de faire la désallocation. En général, une méthode se doit de renvoyer les objets en mode autorelease, sauf cas particulier.
Oh ben ce serait mal foutu, et indiqué dans la doc qu'il reste à la charge du receveur de faire la désallocation. En général, une méthode se doit de renvoyer les objets en mode autorelease, sauf cas particulier.
Je demandais pour vérifier on n'est jamais trop prudent
Bon, je relance le sujet un peu, pour vous faire remarquer qu'Apple a finalement ajouté la méthode permettant de séparer une NSString avec l'un des caractères d'une liste donnée.
Réponses
En ce qui concerne l'objet NSScanner, je ne m'inquiète pas. Je m'inquiète surtout pour l'objet placé grâce à la référence : ¤t dans la méthode scanUpToCharactersFromSet:intoString: est-ce que le résultat stocké dans la référence reçoit un message autorelease ?
Dans le cas d'un accesseur, ça peut servir à quelque chose.
[tt]id obj = [rec myVar]; // (1) en supposant que _myVar ait un retainCount de 1
// beaucoup de code et si possible via des appels de méthodes pour compliquer le debugging
[rec setMyVar:newObj]; // (2)
// encore du code
[obj doSomething]; // crash si pas de retain/autorelease, l'objet désigné par obj a été libéré en (2), ou bien il aurait fallu faire un retain en (1)[/tt]
Ce n'est donc pas si innocent, même si ce genre de cas de figure est plutôt rare (jamais rencontré perso).
Oh ben ce serait mal foutu, et indiqué dans la doc qu'il reste à la charge du receveur de faire la désallocation.
En général, une méthode se doit de renvoyer les objets en mode autorelease, sauf cas particulier.
Je demandais pour vérifier on n'est jamais trop prudent