Retain count et gestion de la mémoire

farhaneit

Membre confirmé
7 Avril 2010
16
0
Bonjour a tous,
Je suis en train de faire quelques tests avec Cocoa en Objective C afin de comprendre un peu plus le fonctionnement des retain count.

Voici mon main.c
Bloc de code:
#import <Cocoa/Cocoa.h>
#import "Person.h"

int main(int argc, char *argv[])
{
	Person *aPerson= [[Person alloc] init];
	NSString  *theName;
	
	NSLog(@"Person retain =%ld\n", [aPerson retainCount]);
	theName= [aPerson name];
	NSLog(@"name= %@\n", theName);
	NSLog(@"Person retain =%ld\n", [aPerson retainCount]);

	[aPerson release];
	NSLog(@"name= %@\n", theName);
	NSLog(@"Person retain =%ld\n", [aPerson retainCount]);

        return NSApplicationMain(argc,  (const char **) argv);
}
Sachant que la méthode name de la classe Personne ne fait que renvoyer le pointeur vers la NSString qui contient le nom. D'ailleurs la voici:
Bloc de code:
-(NSString*)name {
	return name;
}

Voici le résultat de l'éxecution:
Bloc de code:
Person retain =1
name= John
Person retain =1
name= John
Person retain =1152921504606846975
Je ne comprends pas pourquoi la NSString s'affiche alors que j'ai envoyé le message release a aPerson. Il aurait fallu que le programme crashe, non?

Merci!
 
oui max int... le jours ou tu comprendras la difference entre un container signé et non signé tu auras fait un progret immense, la question est comment un memory pool fonctionne, pourquoi ca ne marche pas toujours quand j'essaye d'imprimer le resultat dans une sortie buffered....

parce que je suis multi-thread que la visibilité d'une valeur est scope dependant et thread dependant ecetera :sleep: enfin la chose basique que tu apprends en fesant du C. la gestion des residents maintenant en Obj-C est realise grace a une hash-table B-Tree algo, comme par ailleurs l'arbre des messages envoyes sur chaque objet

ce que tu essayes de voir dans ton main ne marchera pas dans une appli engageant plusieurs threads comme toute appli cocoa, en effet il y a des locks donc timeout ce qu'on appel schedule yield.

lis l'article ownership policy d'apple, c'est la seule chose qui te concerne, il te manque bien trop de pieces pour comprendre comment est geré un memory pool ce n'est pas pour les kidos.

en OOP, tout object "devrait etre" le proprietaire de ses membres quand on alaise avec ca on peut adapter, surtout qu'un retain ne coute rien du tout car le principe meme d'un memory pool c'est d'eviter de fragmenter la memoire et de reutiliser les blocks memoires deja alloués pour un autre task qui c'est terminé, mais tu ne sais pas ce que c'est la framentation de memoire car tu n'as aucune idée de ce qu'est un vm_object dans ton noyau

donc interresse toi a ce que tu peux comprendre, sur cette question tu es intellectuellement limitée car il y a un monde entre toi et cette question.

l'anarchie n'a jamais mené a la connaissance, seul l'etre pragmatique et patient peut la gouter, la connaissance de ses propres limites est la vraie liberté, tu as un profond travail a faire sur toi meme si tu veux devenir, il n'y a aucune honte a ne pas savoir, mais il y a un chemin a ne pas empreinter celui de la fierté et des petites regles bourgeoises de l'ame.
 
Bien que cette réponse m'indique qu'il y a une solution, je ne vois pas pourquoi tu inondes ton message de termes techniques avancés sachant que je suis débutant. Tu assumes que je n'ai pas lu le memory management guide d'apple, donc, il est pédant et peu logique d'utiliser des termes ou des tournures de phrases comme:
des locks donc timeout ce qu'on appel schedule yield.
c'est la framentation de memoire car tu n'as aucune idée de ce qu'est un vm_object dans ton noyau
 
Bien que cette réponse m'indique qu'il y a une solution, je ne vois pas pourquoi tu inondes ton message de termes techniques avancés sachant que je suis débutant. Tu assumes que je n'ai pas lu le memory management guide d'apple, donc, il est pédant et peu logique d'utiliser des termes ou des tournures de phrases comme:

il n'y a aucune honte a ne pas savoir, mais il y a un chemin a ne pas empreinter celui de la fierté et des petites regles bourgeoises de l'ame.
 
mais il y a un chemin a ne pas empreinter celui de la fierté et des petites regles bourgeoises de l'ame.
Est ce que tu pourrais développer un peu plus ce point? Je n'ai pas saisi la subtilité de tes propos.
 
Si tu mets la charrue avant les boeufs, les boeufs ne pourront pas la tirer.

la reponse que tu veux n'est pas la ou tu l'as cherche. Reformule ta Question. petite regle bourgeoise: questionner encore et encore la ou il faut commencer a travailler, petite regle bourgeoise: ne pas mettre sa fierté de coté et ne pas Reformuler sa Question, resultat: destination void.
 
Je ne comprends pas pourquoi après avoir libéré l'instance de Person, j'ai toujours accès aux méthodes et la mémoire n'est pas effacée.
 
La mémoire n'est pas effacée: qu'est-ce que ça veut dire de toute manière ? Par exemple, mettre tout à zéro prend du temps et est inutile.
Le système d'exploitation conserve une trace des blocs mémoire alloués (adresses et tailles), et quand on lui demande un nouveau bloc (par exemple, pour y stocker un objet), nous réserve un bloc dans une zone inoccupée.

Ne te concentre pas trop sur le retain count, parfois il est faux, et parfois, Cocoa fait des choses cachées pour des questions de performances. Par exemple:

Bloc de code:
NSString *toto1 = @"Toto";
NSString *toto2 = @"Toto";

Tu verras que toto1 = toto2, alors que ce sont deux objets différents.