Discussion :

[LeonCosnyd]

Bonjour,

J'ai une question un peu b�te mais je pr�f�re avoir une r�ponse claire !

J'utilise un pointeur que je d�clare comme ceci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

maClasse *monObjet;

Dans mon code je l'initialise avec cette ligne :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

monObjet = new maClasse();

J'ai besoin de r�initialiser mon pointeur pour pouvoir le r�utiliser un peu plus loin ! Je me demande donc si je fais la bonne technique :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
monObjet = NULL;
monObjet = new maClasse();

Je me demande si la premi�re allocation que j'ai fait � �t� lib�r� ? Ou dois-je faire un delete avant ? Mais si je delete monObjet le pointeur est-il toujours utilisable apr�s ?

[M�dinoc]

Normalement, tu dois faire un delete avant.

Mais �a, c'est le vieux C++. Depuis C++11, tu peux faire �a � la place:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

unique_ptr<monObjet> = new maClasse();

Et en C++14, la formule recommand�e, c'est ceci:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

unique_ptr<monObjet> = make_unique<maClasse>();

Le unique_ptr<> se charge de la destruction de l'objet point�.

[LeonCosnyd]

unique_ptr<monObjet> = make_unique<maClasse>();

Je ne savais m�me pas qu'il �tait possible de faire une gestion automatis�e de la m�moire en C++ ! Car l� il s'agit bien d'un fonctionnement similaire � un garbage collector (certes pour une variable) ???

Merci pour l'info !

[Bousk]

Non il s'agit juste d'utiliser une classe et une variable membre, ainsi que la surcharge d'op�rateur pour l'affectation, et profiter du m�canisme de destructeur appel� automatiquement quand la port�e de la variable est d�pass�e.
make_unique allant un peu plus loin en assurant d'�tre exception-proof, et peut-�tre d'autres subtilit�s

[M�dinoc]

Car l� il s'agit bien d'un fonctionnement similaire � un garbage collector (certes pour une variable) ???

Non, c'est juste un objet avec:

1. Un destructeur qui fait un delete sur le pointeur contenu.
2. Une s�mantique de transfert faite correctement cette fois-ci (contrairement � auto_ptr o� c'�tait fait maladroitement) gr�ce � une am�lioration du langage lui-m�me.

En fait, dans C++11, les trois am�liorations majeures du langage lui-m�me sont:

1. La s�mantique de transfert support�e par le langage (les classes peuvent dor�navant avoir un constructeur de d�placement en plus du constructeur de copie).
2. Les variadic templates (templates � nombres de param�tres variables; c'est ce qui permet de faire des wrappers "parfaits" de fonction, et c'est utilis� pour make_unique<> mais pas seulement)
3. Les expressions lambda, qui ne sont pas utilis�es dans le cadre de cette discussion mais ont leur utilit�.

Ensuite, la biblioth�que standard a re�u diverses am�liorations, dont la plupart d�pendent directement des am�liorations du langage:

• Le unique_ptr<>;
• le template function<> qui harmonise et simplifie tout le syst�me de foncteurs et pointeurs de fonction;
• le support natif du multithreading via la classe thread;
• le support natif de la g�n�ration de nombres al�atoires (je ne crois pas que celui-ci d�pende d'une am�lioration du langage)
• etc.

[koala01]

Salut,

En fait, les pointeurs intelligents sont ce qu'il convient d'appeler des "capsules RAII", car elles applique le (tr�s mal nomm� � mon sens) principe du m�me nom (RAII).

Ce principe est en r�alit� l'acronyme (tu le sais surement, les d�veloppeurs adorent ce genre de choses ) de Ressource Acquisition Is Initialisation et part du principe que lorsque tu cr�es une donn�es qui a besoin d'une ressource, le simple fait de cr�er ta donner doit s'assurer que la ressource dont elle a besoin sera bel et bien disponible. (Tu remarqueras au passage que je viens � peu pr�s de t'expliquer le fonctionnement classique que l'on peut observer pour � peu pr�s n'importe quel constructeur ). C'est gr�ce � ce principe que l'on peut depuis d�j� bien longtemps avoir un code proche de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
int main(){
    std::ifstream ifs("fichier.txt");
    /* ici, le fichier a été ouvert et est utilisable, ou bien, ifs est dans un état invalide
     * et le test échoue
     */
    if(ifs){
        /* génial, on peut continuer */
   } 
}

Mais cet accronyme va plus loin, car, il y a toujours une sorte de "jeu en miroir" : si quelque chose se fait � la cr�ation, c'est sans doute qu'il y a "quelque chose" qui pourra le d�faire � la destruction. Ainsi, le RAII stipule que toutes les ressources dont "quelque chose" est propri�taire devront �tre correctement d�truite ... lorsque ce quelque chose est d�truit.
Modifions un peu le code que je viens de donner afin de comprendre:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
int main(){
    if(someTest){
        std::ifstream ifs("fichier.txt");
        /* ici, le fichier a été ouvert et est utilisable, ou bien, ifs est dans un état invalide
         * et le test échoue
         */
        if(ifs){
            /* génial, on peut continuer */
    }
   } // ifs est automatiquement détruit ici
   return 0;
}

Le RAII nous donne la garantie que, lorsque ifs est d�truit, les ressources mat�rielles que la classe std::ifstream utilise en interne seront correctment lib�r�es. Dans le cas pr�sent, nous aurons par exemple entre autre la certitude que le "lock" �ventuellement plac� par le syst�me d'exploitation sur le fichier "fichier.txt" sera bel et bien lev�, et ce, sans avoir quoi que ce soit � faire.

L'�norme avantage, c'est que les d�veloppeurs ne valent souvent pas mieux que n'importe quel utilisateur, et c'est tout � fait normal : ce sont eux m�me des utilisateurs. Et, en tant que tel, il faut les consid�rer comme des "imb�ciles distrait". Et ne crois pas que je me consid�re meilleur qu'un autre � ce sujet l� (je ne suis d'ailleurs pas loin de penser que les meilleurs d�veloppeurs sont ceux qui sont conscients de cette faiblesse et qui mettent tout en oeuvre pour �viter les catastrophes qu'elle peut engendrer )

Enfin, revenons � nos moutons : les pointeurs intelligents vont appliquer le m�me principe et s'assurer que la m�moire allou�e au pointeur sous jascent sera effectivement lib�r�e exactement au moment opportun, c'est � dire:

• lorsque la variable de type std::unique_ptr sera d�truite (parce qu'on sort de sa port�e, ou parce qu'on la retire de la collection qui la contient)
• lorsque le dernier std::shared_ptr r�f�ren�ant la m�moire allou�e au pointeur sous-jascent sera d�truit (parce que l'on sort de sa port�e ou parce qu'on le retire de la collection qui la contient)

Cela n'a donc absolument rien � voir avec un quelconque m�canisme de Garbage Collector: typiquement, le garbage collector va parcourir la liste des r�f�rences qui existent pour savoir si elles sont encore utilis�es, et ne supprimer que celles pour lesquelles ce n'est plus le cas; ce qui occasionne (allez, soyons sympa : qui peut occasionner) un "l�ger retard" (parfois m�me "pas si l�ger que ca" d'ailleurs) entre le moment o� la r�f�rence � supprimer cesse d'�tre utile et le moment o� elle est effectivement supprim�e.

Les pointeurs intelligents vont quant � eux occasionner la lib�ration imm�diate de la m�moire allou�e au pointeur sous-jacent. Ainsi, si tu as un code proche de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
int main(){
   for(int i= 0;i<10;++i){
      auto ptr = std::make_unique<int>(i);
      std::cout<<*(ptr.get())<<"\n";
   } // on sort de la portée de ptr, ptr est donc détruit
   return 0;
}

lorsque ptr est d�truit, la m�moire allou�e au pointeur sous-jacent est directement lib�r�e elle-aussi

[zobal]

En fait, les pointeurs intelligents sont ce qu'il convient d'appeler des "capsules RAII", car elles applique le (tr�s mal nomm� � mon sens) principe du m�me nom (RAII).

Salut,

Merci pour cette explication claire du RAII. Cependant, il me semble que le RAII et les pointeurs intelligents sont quand m�me assez orthogonaux.

Le RAII permet de lier le cycle de vie d'une ressource � celle d'un objet (http://en.cppreference.com/w/cpp/language/raii). �a correspond donc � la construction/destruction et �a s'utilise avec ou sans pointeur intelligent.

Les pointeurs intelligents permettent de g�rer la dur�e de vie des objets et �a s'applique "avec ou sans RAII � l'int�rieur de l'objet".

Maintenant, c'est vrai qu'on peut consid�rer qu'un attribut est d�j� une ressource et qu'il y a donc toujours du RAII. De plus, effectivement, un pointeur intelligent va automatiquement lancer la destruction et donc indirectement terminer le RAII. C'est peut-�tre cela que tu appelles "capsule RAII" (cppreference parle de "RAII wrapper"). Mais le RAII existe �galement sans pointeur intelligent.

Et pour les shared_ptr, ce n'est effectivement pas du "garbage collector" mais plut�t du "reference counting" d�terministe (comme en python je crois).

[JolyLoic]

Je ne savais m�me pas qu'il �tait possible de faire une gestion automatis�e de la m�moire en C++ ! Car l� il s'agit bien d'un fonctionnement similaire � un garbage collector (certes pour une variable) ???

Contrairement aux autres r�ponses, je r�pondrais plut�t "oui" � cette question. Il s'agit bien l� d'un m�canisme de type garbage collection, m�me s'il poss�de des caract�ristiques assez diff�rente des garbage collectors qui peuvent exister en Java et en C# par exemple. Les principales diff�rences sont les suivantes :

• Tu choisis pour chaque objet le mode de collection qui sera le plus appropri� au moment de sa construction (g�r� sur la pile, dans un conteneur, par unique_ptr, par shared_ptr...), l� o� en Java/C#, il existe un m�canisme unique pour tous les objets (c'est un peu plus de travail, mais �a apporte des choses int�ressantes en terme de perfs)
• Ces m�canismes sont d�terministes : On sait quand une ressource sera lib�r�e, et on sait qu'elle sera lib�r�e. Ce qui n'est pas le cas en Java/C#. Une cons�quence est qu'on peut mettre du code int�ressant dans les destructeurs, l� o� les finalizers sont globalement inutiles, et o� d'autre m�canismes moins �l�gants ont d� �tre utilis�s (les using du C#, les try-with-resources du Java)
• Ces m�canismes sont � manier avec pr�caution quand on a des boucles, l� ou un garbage collector classique g�re les boucles sans soucis
• Ces m�canismes sont plus �conomes en m�moire. Leur impact en performance est diff�rent (il y a des cas o� un garbage collector sera plus efficace, mais c'est assez rare).

R�guli�rement quand je dis "C++" � des d�veloppeurs Java, ils me r�pondent "ah, oui, le langage o� il faut lib�rer la m�moire soi-m�me". Et �a a tendance � m'agacer, car �a montre que ces gens l� critiquent non pas le C++ tel qu'il est (et pourtant, il y en aurait des critiques recevables !..), mais une image totalement fauss�e de ce langage, qui �tait peut-�tre vraie il y a 20 ans. �a fait des ann�es que dans du code � moi (par opposition � du code existant o� je fais juste une micro-modification), je n'ai pas �crit un seul delete.