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.