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).

[M�dinoc]

On peut avoir tu RAII hors des pointeurs intelligents bien s�r, mais en C++, on ne peut pas avoir de pointeurs intelligents sans RAII.

[zobal]

Oui, c'est ce que je voulais dire par :

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.

Et si, tu peux avoir des pointeurs intelligents sans RAII. Exemple (de ce qu'il ne faut pas faire) :

Code :

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

1
2
3
4
5
6
7
8
9
10
struct A {
    int * p;
    A() { p = new int; }
    // pas de destruction de p => pas de RAII pour p
};
 
int main() {
    unique_ptr<A> a = make_unique<A>();  // indirectement, RAII incomplet
    return 0;
}

On aurait �galement le probl�me avec un objet classique (sans le pointeur intelligent) et c'est pour �a que je dis que RAII et pointeur intelligent sont relativement orthogonaux (les pointeurs intelligents g�rent la dur�e de vie de l'objet point� mais pas les ressources internes de l'objet).

[M�dinoc]

La partie non-RAII de ton code ne fait pas partie du pointeur intelligent, �a ne suffit donc pas � dire qu'on peut avoir un pointeur intelligent sans RAII.

[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.

[zobal]

La partie non-RAII de ton code ne fait pas partie du pointeur intelligent, �a ne suffit donc pas � dire qu'on peut avoir un pointeur intelligent sans RAII.

� mon avis, tu confonds la dur�e de vie d'un objet et celle de ses ressources internes.
Un pointeur intelligent g�re la dur�e de vie de l'objet alors que le RAII concerne les ressources internes. Il s'agit de deux niveaux diff�rents et qui ne sont pas si interd�pendants que tu sembles le dire.

[koala01]

C'est bien pour cela que j'ai parl� de capsule RAII...

En fait, j'aurais du dire que les pointeurs intelligents permettent d'appliquer le (et plus pr�cis�ment de terminer l'application du) RAII sur les ressource dont la pratique a fait que le d�veloppeur normalement pris la responsabilit� de la lib�ration.

En effet, un appel � new (ou new[]) impose que la ressource soit lib�r�e par delete (respectivement delete[]) "au plus tard avant de perdre d�finitivement toute r�f�rence � cette ressource".

Or, appliquer le RAII manuellement sur ce genre de ressource est pour le moins hasardeux:

1. Si on ne fait pas une copie en profondeur, on observe un partage de la ressource qui occasionnera plusieurs tentatives de lib�ration de celle-ci
2. Si on ne pense pas � faire en sorte que l'�l�ment qui demande l'allocation de la ressource veille � la d�truire lorsqu'il est d�truit, on obtient une fuite m�moire
3. Si on essaye de d�truire cette ressource d'une autre mani�re, il devient rapidement difficile de pr�voir tous les chemins d'ex�cution possible, ne serait-ce que parce que le lancement d'une exception cr�era un chemin alternatif
4. Si l'�l�ment est responsable de l'allocation plusieurs ressources par new (ou par new[]) et que l'une seule d'elles �choue il devient rapidement difficile de savoir lesquelles ont �t� allou�es (et doivent �tre lib�r�es) et lesquelles n'ont pas encore �t� lib�r�es.
5. Dans le cas de ressources multiples cr��es dans le constructeur, il faut savoir que si l'une d'elle �choue, une exception est lanc�e et l'objet en cours de construction est -- purement et simplement -- consid�r� comme non construit, si bien qu'il n'y aura aucune tentative de le d�truire par la suite

Maintenant, il est tout � fait vrai que les pointeurs intelligents ne peuvent appliquer le RAII que sur des ressources qui l'appliquent elles-m�me correctement en interne. Et c'est bien pour cela que l'on insiste pour que tout pointeur renvoy� par new (ou new[])soit directement pris en charge par un pointeur intelligent, ou mieux encore, qu'on fasse appel au fonction de cr�ation "s�curis�e" de pointeurs intelligents.

[gl]

� mon avis, tu confonds la dur�e de vie d'un objet et celle de ses ressources internes.
Un pointeur intelligent g�re la dur�e de vie de l'objet alors que le RAII concerne les ressources internes. Il s'agit de deux niveaux diff�rents et qui ne sont pas si interd�pendants que tu sembles le dire.

En l�occurrence, je pense plut�t que tu ne comprends pas le terme "capsule RAII" dans le m�me sens que Medinoc et des autres intervenants (qui est globalement le sens usuellement utilis�).
Le terme RAII s'utilise vis � vis de la lib�ration de nos propres ressources et non transitivement vis � vis des ressources de nos ressources.

La capsule RAII qu'est le pointeur intelligent l'est vis � vis de l'objet qu'il r�f�rence. C'est pr�cis�ment parce qu'il g�re la dur�e de vie de l'objet point� qu'il est une capsule RAII pour celui-ci

Il garanti donc uniquement qu'� la destruction dudit pointeur, l'�l�ment qu'il r�f�rence sera lui-m�me lib�r� et ne pr�sume rien des ressources de cet objet r�f�renc�. L� on rejoint effectivement ton point de vue sur le r�le du pointeur intelligent mais, sauf � consid�rer qu'une classe qui lib�re ces ressources � la destruction n'applique pas le RAII car rien ne garanti que ces ressources vont bien lib�rer leurs ressources propres, �a en reste du RAII.

[zobal]

Ok. C'est pour cela que j'avais fait cette remarque dans mon premier message :

... C'est peut-�tre cela que tu appelles "capsule RAII" (cppreference parle de "RAII wrapper").

De l� � parler de sens "usuellement utilis�", �a me parait exag�r� : le terme "RAII wrapper" n'apparait pas dans la norme et seulement tr�s rarement dans les docs classiques (cppreference, isocpp, core guidelines...), parfois d'ailleurs pour un sens diff�rent. Et � mon avis, c'est tant mieux car je ne vois pas vraiment l'int�r�t d'un terme de plus pour un concept aussi �vident, � part peut-�tre donner raison � la r�putation de langage complexe du C++.

[gl]

De l� � parler de sens "usuellement utilis�", �a me parait exag�r� : le terme "RAII wrapper" n'apparait pas dans la norme et seulement tr�s rarement dans les docs classiques (cppreference, isocpp, core guidelines...), parfois d'ailleurs pour un sens diff�rent. Et � mon avis, c'est tant mieux car je ne vois pas vraiment l'int�r�t d'un terme de plus pour un concept aussi �vident, � part peut-�tre donner raison � la r�putation de langage complexe du C++.

Sauf erreur de ma part, RAII tout court n'apparait pas dans la norme (en tout cas, je viens de chercher dans les versions 98 et 11 sans le trouver).

Et c'est bien la notion de "capsule RAII" (RAII wrapper) qui est g�n�ralement utilis�e pour d�signer les objets encapsulant un autre objet - non-RAII mais possesseur de ressources - en lui apportant le RAII vis � vis de ses ressources.
Apr�s que ce terme apparaisse rarement n'est pas �tonnant car il n'y a que peu d'objets de ce type (essentiellement les pointeurs intelligents pour les pointeurs et les verrous pour les mutex), la majorit� des objets impl�mentant directement le RAII sans n�cessiter de telles capsules.

[foetus]

Et c'est bien la notion de "capsule RAII" (RAII wrapper) qui est g�n�ralement utilis�e pour d�signer les objets encapsulant un autre objet

Oui et non ici on parle d'un pointeur nu C qui n'a pas les m�canismes C++ constructeur/ destructeur (au moins ceux l�)

Donc c'est normal d'utiliser une classe C++ et englob� ce pointeur nu C, classe qui va g�rer ce pointeur.

On le fait tout �galement avec un lock, mutex, handle, ...

[gl]

Et il ne me semble pas avoir dit autre chose, du coup j'ai du mal � comprendre le "oui et non" (au passage, la citation en coupant la fin de la phrase change pas mal le sens de la phrase. C'est assez maladroit)

[Ehonn]

Apr�s que ce terme apparaisse rarement n'est pas �tonnant car il n'y a que peu d'objets de ce type (essentiellement les pointeurs intelligents pour les pointeurs et les verrous pour les mutex)

et std::vector

[foetus]

Et il ne me semble pas avoir dit autre chose, du coup j'ai du mal � comprendre le "oui et non" (au passage, la citation en coupant la fin de la phrase change pas mal le sens de la phrase. C'est assez maladroit)

Parce que ce n'est pas un objet qui est encapsul� : ce sont soit des pointeurs soit des structures avec des pointeurs, mais en aucun cas des classes C++