Discussion :

[Bernulf75]

Bonjour,

existe-il un moyen simple en C++ pour savoir si un objet et détruit ou non ?
exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
int main()
{
 ClassA *ptr = new ClassA();
 delete ptr;
 // ptr = NULL; // si nous ne faisons pas cette instruction
 if( ptr is NULL) // existe t'il un test de ce type ?
 {
 } 
}

[koala01]

Salut,

Le plus sur moyen de s'assurer qu'un objet est détruit est de laisser le compilateur gérer la durée de vie des objet, et donc de ne pas recourir à l'allocation dynamique de la mémoire.

En effet, lorsque tu déclare une variable sans passer par new, l'objet correspondant est créé lors de la déclaration de la variable et automatiquement détruit lorsque l'on quitte la portée dans laquelle la variable a été déclarée (comprend : quand on passe l'accolade fermante dans laquelle la variable a été déclarée):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
void foo()
{
    if(untest)
    {
        Type variable /* ou Type variable = Type(arguments) */;
        // travailler avec variable
    } // variable est automatiquement détruite ici
    // variable n'existe meme plus aux yeux du compilateur ici
   variable.someStruff(); // KO : le compilateur ne connait pas variable
}

Autrement, et pour répondre à ta question, si l'on ne met pas l'instruction ptr = NULL après un delete ptr;, il n'y a aucun moyen de savoir si l'objet pointé par ptr a été détruit ou non, à part, bien sur, celle d'encapsuler ptr dans une portée qui ne peut rien contenir après la ligne contenant delete ptr;.

C'est la raison pour laquelle C++11 (la nouvelle norme parue il y a peu ) fournit quelques smart pointers.

L'idée est de déterminer qui a la responsabilité de la destruction de l'objet pointé en fonction du type de smart pointer utilisé, et de pouvoir déterminer, grace à ces smart pointers si le pointeur sous jascent est encore valide ou non

Tu comprendras donc que, l'idéal est d'user et d'abuser de ces pointeurs intelligents plutot que d'utiliser des pointeurs nus, à moins de savoir exactement ce que l'on fait

Le principal problème, c'est que l'utilisation de pointeurs nus va souvent de paire avec un manque de connaissance de "qui a la responsabilité de quoi", que ce soit parce que le développeur ne s'est, tout simplement, pas posé la question ou parce que la situation est loin d'être aussi simple que cela

[Dalini71]

Bonjour,

J'en profite pour poser une question qui me passe par la tête :
Dans un gros programme, si on remplace tous les pointeurs nus par des smart_pointers, ne risque-t-on pas de voir apparaître un chute des performances ?

[koala01]

Pour être franc, je suis totalement incapable de te répondre...

Il y a certes une indirection supplémentaire, mais les pointeurs intelligents sont des classes templates (résolues à la compilation) et leurs fonctions sont inlinées (l'appel de la fonction est, d'office, remplacé par le code de la fonction )

J'aurais tendance à dire (mais c'est à confirmer à coup de benchmarks ) que, si goulot d'étranglement il y a, ce sera au niveau de la construction (en ce, y compris la copie) et de la destruction des objets sous jascents, mais que c'est, de toutes manières, un problème que l'on a systématiquement lorsque l'on recours à l'allocation dynamique de la mémoire, mais que leur utilisation (hors création et destruction) ne devrait pas se sentir outre mesure

En outre, une fuite mémoire est souvent bien pire en terme de performances que le léger overhead que l'on pourrait peut etre constater

[Ekleog]

Bonjour,

J'en profite pour poser une question qui me passe par la tête :
Dans un gros programme, si on remplace tous les pointeurs nus par des smart_pointers, ne risque-t-on pas de voir apparaître un chute des performances ?

En théorie, aucun pour unique_ptr.
shared_ptr peut en introduire un assez facilement si les pointeurs n'étaient pas ref-counted avant. Sinon, il y a de bonnes chances que l'overhead diminue (enfin, si on considère que les implémenteurs sont doués, quoi).
weak_ptr est, iirc, légèrement plus qu'un pointeur nu (un déréférencement supplémentaire). En échange, il permet de savoir si le pointeur est toujours "valide".

J'espère ne pas en avoir oublié !

(Bien sûr, toute cette "analyse" considère que les fonctions sont inlinées, ce que devrait faire tout compilateur qui n'est pas en -O0 -ggdb3 ...)

[Dalini71]

Merci de vos réponses.

On pourrait donc limite en déduire une guideline pour le C++11 qui serait de faire en sorte que le programme comporte le moins de pointeurs nus possible.

[Ekleog]

Les pointeurs nus ont toujours une utilité : ils sont aux unique_ptr ce que sont les weak_ptr aux shared_ptr. (J'espère que c'est compréhensible !)

D'ailleurs, quelqu'un avait envisagé de faire quelque chose comme ceci, pour marquer l'appartenance à un unique_ptr, et pour pouvoir être totalement débarassé des pointeurs "nus" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

template <typename T> using owned_ptr = T*;

[koala01]

Attention, je n'ai jamais dit que les pointeurs nus n'avaient aucune utilité non plus!!!

Après tout, on a fait avec des pointeurs nus pendant des années sans forcément que cela n'aie posé problème

Ce que je dis, c'est qu'il faut être particulièrement prudent lorsqu'on utilise les pointeurs nus, entre autres parce qu'ils posent toujours le problème de savoir "qui s'occupe de quoi" si ce n'est pas clairement documenté.

On a, en effet, très vite fait de libérer la mémoire sur laquelle ils pointent dans un endroit du code où l'on n'aurait pas du le faire ou, au contraire, d'oublier de le faire là où c'est nécessaire

Les pointeurs intelligents présentent l'avantage qu'ils nous obligent en quelque sorte --ne serait ce que pour arriver à choisir le type de pointeur intelligent le plus cohérent pour un usage donné -- à nous poser les bonnes questions, comme "qui est le propriétaire "légal" du pointeur" ou "est ce que ce pointeur sera copié" ou encre "est ce que plusieurs objets utiliseront le meme pointeur à un instant T" et, une fois que le choix a été fait, de s'assurer que la politique choisie sera correctement appliquée

Contrairement aux bibliothèque standard d'autres langages, celle de C++ est conçue pour ne rien imposer à personne, mais pour s'imposer d'elle-même en terme de facilité et de sécurité (il est toujours possible à quiconque souffrant du NIH d'implémenter ses propres classes de collection ou de chaines de caractères ou de n'importe quoi d'autre, mais on pourrait presque dire qu'il le fait "à ses risques et périls" )

Les pointeurs intelligents sont tirés du même tonneau : le langage n'obligera jamais à y recourir de manière systématique et, si obligation il y a, ce sera sans doute au niveau des règles de codage d'un projet ou d'une entreprise, mais, l'usage aidant, leur utilisation finira très certainement par s'imposer, au même titre que celles de la plupart des classes issues de l'espace de noms std (ou que les possibilités avancées mises en place en C++11), par la sécurité et la facilité d'utilisation qu'ils apportent