Dans ce cas petit rappel, ne pas oublier de faire un release sur la mutableCopy une fois qu'on n'en a plus besoin (toujours un release ou autorelease pour balancer un retain, un init, ... mais aussi un ...copy !)
Il vaudrait mieux faire un autorelease sur ton tabRetour juste avant de le transmettre en valeur de retour.
return [tabRetour autorelease];
Charge à la méthode ayant appelée cette fonction de faire un retain dessus si besoin.
... Mais si ce tableau est destiné à être lui même ajouté à une collection (tableau, dico ...) c'est la collection qui fera un retain dessus (puis de chargera de le libérer ...)
Pourquoi personne ne lit les docs Apple sur la gestion de la mémoire ? Ca consiste en 5 ou 6 règles simples mais à suivre à la lettre, après ça tout est logique et on n'a plus de prise de tête si on respecte ces règles simples...
J'ai toujours eu du mal avec la gestion de la mémoire. Mais là il me semble que l'objet retourné par la méthode n'est pas retenu par le récepteur ce qui provoque une libération inopiné de l'objet. Sauf, que j'ai pas souvenir de faire un retain sur un objet reçu. Peut être que je fait mal aussi !
Bon j'ai viré l'autorelease et j'ai toujours mon pb mémoire, donc si j'ai bien compris une tentative d'accès à une adresse mémoire où devrait se trouver un objet qui n'y ai plus.
Le hic c'est que pour débugger ça j'ai mis de breakpoints et là plus de pb, puis ça revient... BIgre un pb d'objets en mémoire aléatoire... Je réépluche mon code mais si avec les breakpoints l'erreur ne se produit plus...
Pourquoi encapsuler ta stringWithCString dans un "NSString alloc/initWithString" ? Autrement dit créer une NSString à partir... d'une NSString ? Un "retain" sur ta stringWithCString aurait amplement suffi... Ou encore mieux, remplacer stringWithCString:encoding par un alloc+initWithCString:encoding !
C'est bcp plus logique et aussi plus court comme code... plutôt que de créer un objet autorelease via un constructeur de comodité et de recréer un objet NSString à partir de cette string pour avoir un objet avec un retainCount de 1... comme tu fais... autant tout de suite créer ta NSString non-autorelease quoi.
...ce qui est le cas automatiquement quand tu choisis "Build & Analyze" dans le menu "Build" de Xcode 3.2 !
C'est quand même la grande nouveauté de Xcode 3.2 (Snow Leopard only), l'intégration de cette analyse statique par Clang/LLVM... ça m'étonne que tu sois passé à côté schlum, toi qui suis en plus pas mal ce genre de projets et nous avait informé en avant première... maintenant que c'est intégré à Xcode 3.2 tu devrais quand même être au courant comme tout le monde, non ? ;D
Par défaut c'est GGC 4.2 ("system default") qui est le compilateur de mes projets, et je suis obligé chaques fois d'aller changer ce réglage pour tout nouveau projet ... ???
'Vais aller voir si on peut modifier ça dans les prefs d' xCODE :P
[EDIT] Bouh !!! Je t'ai vu Ali ! t'as édité ton post ! :P
[EDIT2]Â en plus tu postes pile poile au PBT !! (PJ)
À vrai dire, je suis toujours en PPC / G5 chez moi et j'ai pas Snow Leopard, donc niveau nouveautés je suis un peu largué (au boulot, on évite d'upgrader Xcode tous les 4 matins )
Par ailleurs, je trouve que Snow Leopard est du foutage de gueule qui n'apporte strictement rien d'intéressant, donc même si j'avais du Intel-inside, no way :P
Bah, pour 29€ seulement, côté utilisateur je vois pas vraiment de nouveautés, mais côté développeur, rien que pour Xcode 3.2 justement et les nouvelles API aussi utilisant les blocks (ça tu peux pas dire que tu connais pas, tu nous en as fait la pub ;D), genre [tt][anArray enumerateWithBlock:^(int idx, id obj) { ... }];[/tt] et autre. C'est pas méchant (quoique le Static Analyzer, vu la taille de mes projets donc les bourdes potentielles, et la façon superbe dont c'est intégré à Xcode avec les flèches et tout, je m'en sers vraiment souvent) mais pour le prix en tant que dev je trouve que ça valait le coup
@ClicCool : Ah mais c'est vrai ça, t'as l'oeil ! Enfin j'ai 7 secondes de retard quand même ;D Et toi n'oublies pas d'éteindre tes dents et d'aller brosser la lumière des WC...
Au temps pour moi, c'était la fin de semaine, j'avais pas toutes mes neurones allumées et besoin de repos (heu vraiment, d'ailleurs, pas que pour ça, p*tain de semaine chargée :-S) :P Mais ayé le WE a rechargé mes batteries, promis j'le r'frais plus ! ;D
Réponses
Juste une dernière question, y-at'il au final un pb mémoire ? Il faut faire un release ?
Charge à la méthode ayant appelée cette fonction de faire un retain dessus si besoin.
... Mais si ce tableau est destiné à être lui même ajouté à une collection (tableau, dico ...) c'est la collection qui fera un retain dessus (puis de chargera de le libérer ...)
oups, là aussi le tableau qu'est tabRetour fera lui-même un retain sur le mutableDictionary que tu y insères.
me parrait plus approprié
EDIT : Mais l'autorelease me fait un
Il manque pas un retain quelque part ?
Cette erreur est dû au fait qu'il essaye d'accéder à un objet qui a été libéré !
A quel niveau ça te fait ça ? ???
Ca consiste en 5 ou 6 règles simples mais à suivre à la lettre, après ça tout est logique et on n'a plus de prise de tête si on respecte ces règles simples...
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/20000994
J'ai toujours eu du mal avec la gestion de la mémoire. Mais là il me semble que l'objet retourné par la méthode n'est pas retenu par le récepteur ce qui provoque une libération inopiné de l'objet.
Sauf, que j'ai pas souvenir de faire un retain sur un objet reçu. Peut être que je fait mal aussi !
Le hic c'est que pour débugger ça j'ai mis de breakpoints et là plus de pb, puis ça revient... BIgre un pb d'objets en mémoire aléatoire... Je réépluche mon code mais si avec les breakpoints l'erreur ne se produit plus...
PS : j'ai lu la doc
C'est dans une méthode d'envoie de requête à la base de donnée...
J'avais écris
J'ai corrigé
En sachant quen fin de méthode il y a :
C'est bcp plus logique et aussi plus court comme code... plutôt que de créer un objet autorelease via un constructeur de comodité et de recréer un objet NSString à partir de cette string pour avoir un objet avec un retainCount de 1... comme tu fais... autant tout de suite créer ta NSString non-autorelease quoi.
Merci
Il traite tous ces petits problèmes et dit où la mémoire est mal gérée.
À moins que tu ne l'aies testé et qu'il t'aie renvoyé tellement d'erreurs que tu n'as pas osé nous le dire... ;D
Tu veux parler du Garbage Collector ? C'est pas du tout une bonne idée... Gérer correctement sa mémoire est une très bonne école.
Peut-être voulait-il parler de l'analyse du code faite par Clang-LLVM dans xCode 3.2 ?
Xcode (X majuscule c minuscule :P) 3.2 fait de l'analyse Clang-LLVM de base ? ???
Ben, si, dans le projet, on choisi Clang-LLVN comme compilateur, oui.
C'est quand même la grande nouveauté de Xcode 3.2 (Snow Leopard only), l'intégration de cette analyse statique par Clang/LLVM... ça m'étonne que tu sois passé à côté schlum, toi qui suis en plus pas mal ce genre de projets et nous avait informé en avant première... maintenant que c'est intégré à Xcode 3.2 tu devrais quand même être au courant comme tout le monde, non ? ;D
Un peu de doc si t'as pas Xcode 3.2...
Ben je dois pas avoir de chance moi alors.
Par défaut c'est GGC 4.2 ("system default") qui est le compilateur de mes projets, et je suis obligé chaques fois d'aller changer ce réglage pour tout nouveau projet ... ???
'Vais aller voir si on peut modifier ça dans les prefs d' xCODE :P
[EDIT] Bouh !!! Je t'ai vu Ali ! t'as édité ton post ! :P
[EDIT2]Â en plus tu postes pile poile au PBT !! (PJ)
(au boulot, on évite d'upgrader Xcode tous les 4 matins
Par ailleurs, je trouve que Snow Leopard est du foutage de gueule qui n'apporte strictement rien d'intéressant, donc même si j'avais du Intel-inside, no way :P
C'est pas méchant (quoique le Static Analyzer, vu la taille de mes projets donc les bourdes potentielles, et la façon superbe dont c'est intégré à Xcode avec les flèches et tout, je m'en sers vraiment souvent) mais pour le prix en tant que dev je trouve que ça valait le coup
@ClicCool : Ah mais c'est vrai ça, t'as l'oeil ! Enfin j'ai 7 secondes de retard quand même ;D
Et toi n'oublies pas d'éteindre tes dents et d'aller brosser la lumière des WC...
Encore un truc à mon sens qui rend le code moins lisible :P
[Musique de suspense]
La réponse au prochain poste.....
:P
Mais ayé le WE a rechargé mes batteries, promis j'le r'frais plus ! ;D