[[object retain] autorelease] explication

AliGator

Pour C# je dis pas, c'est vrai qu'il a des très bons points ce langage

Pour Java et ObjC+GC... tu sais sans doute ce que je pense du GC :P

Après en ObjC, le "il faut que le programmeur ait prévu le truc", c'est là  qu'on voit la différence entre le programmeur du dimanche qui comprend pas trop les implications de ce qu'il fait et le programmeur de métier qui a fait de l'archi et respecte les conventions de nommage et les règles de gestion mémoire :P

mpergand

Pour rebondir sur le sujet, il est parfois nécessaire d'implémenter un RefCounter, notamment pour QuickTime et CoreAudio.

Mais je n'arrive pas à  une solution qui me satisfasse


J'ai une classe SmartObject qui gère donc un refCount, et une sous classe est créée pour chaque type d'objet, comme une MusicSequence QT ou une AudioUnit CoreAudio.

Exemple:

<br />class SmartMusicSequence : public SmartObject&lt;MusicSequence&gt;{<br /><br />					<br />	public:<br />				<br />			SmartMusicSequence(MusicSequence mt) : SmartObject&lt;MusicSequence&gt;(mt) {}<br />	virtual ~SmartMusicSequence&nbsp; () { releaseSmartObject(); }<br />				<br />virtual	void releaseSmartObject() <br />		{ <br />		if(count()==0)<br />			{<br />			if(musicSequence())<br />				{						//printf(&quot;release sequence&#092;n&quot;);<br />				DisposeMusicSequence(musicSequence());<br />				}<br />			}<br />		}<br />};<br />

releaseSmartObject est une fonction abstraite de SmartObject qui est appelée quand le compteur passe à  zéro.
Seulement, je suis obligé de faire de même dans le destructeur de la sous classe: virtual ~SmartMusicSequence  () { releaseSmartObject(); }
C'est ballot, et de plus je dois tester le compteur !
Tout ça parce que dans le destructeur de SmartObject, je ne peux pas appeler la fonction releaseSmartObject, car le destructeur de la sous classe SmartMusicSequence a déjà  été exécuté.
Ca semble insoluble, mais si quelqu'un à  une idée pour contourner le problème ça m'intéresse.


Pour illustrer la complexité du C++, voici le code de gestion du RefCounter:

<br />		 <br />	SmartObject(SmartObject&amp; obj) : _refCount(NULL)<br />			{	<br />			//printf(&quot;copie SmartObject&#092;n&quot;);<br />			 *this=obj;<br />			}<br />		<br /> virtual SmartObject&amp;&nbsp; operator=(SmartObject&amp; obj) <br />			{			<br />			if(this==&amp;obj) return *this;		// copie sur lui-même !<br />											<br />			if(this-&gt;_refCount!=obj._refCount)	// les objets n&#39;ont pas le même smartObject<br />				if(this-&gt;_refCount!=NULL)<br />					releaseSmartObjectIfNeeded();<br />						<br />			this-&gt;_refCount=obj._refCount;<br />			this-&gt;_smartObject=obj._smartObject;<br />			incrementCounter();<br />						<br />			return *this;<br />			}<br /><br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; void releaseSmartObjectIfNeeded()<br />				{<br />				if(count()==0)<br />					{<br />					releaseSmartObject();<br />					free(_refCount); //printf(&quot;free refCount&#092;n&quot;);<br />					}<br />				else<br />					decrementCounter();<br /><br />				}<br />

Et avec un objet bidon SObject:

<br />SObject s1(100);<br /><br />SObject s2(200);<br />SObject s3(s2);	// copie<br />SObject s4=s2;	// copie<br />s2=s1;			// affectation<br />

ça donne:

destructeur SObject() 200
release SObject 200
destructeur SObject() 200
destructeur SObject() 100
release SObject 100
destructeur SObject() 100

4 objets sont créés et seulement deux refCount (s1 et s2)

On voit bien ici qu'en C++, gérer l'allocation automatique c'est relou !

En ObjC, on a que de l'allocation dynamique, ce qui simplifie bien les choses.
Mais on a encore des trucs tordus comme on l'a vu au dessus.

A mon avis, dans l'avenir ce type de langage va disparaà®tre au profit de langage de type java, corroboré par le fait qu'à  terme tous les OS tourneront dans une machine virtuelle.

Ca risque de ne pas plaire à  tout le monde