Pointeurs nus et code « sûr »

Bonjour.
Tout d'abord, merci de ne pas me crier dessus à la vue du sujet…

J'aimerais avoir des pistes pour maximiser la sûreté d'un code qui utilise des pointeurs, alors qu'on n'a pas la possibilité d'utiliser des pointeurs intelligents.

Je pose cette question dans le cas général, mais pour l'application qui m'intéresse il y a beaucoup de pointeurs (pour usage polymorphique), stockés dans des conteneurs.
Certains pointeurs sont stockés dans plusieurs conteneurs en même temps, mais normalement, un seul de ces conteneurs est chargé de désallouer la mémoire.
Enfin je veux dire que c'est lorsque l'on doit en détruire un en particulier (de tous ceux qui peuvent contenir le pointeur en question) que l'on libère la mémoire.
Ce n'est pas moi qui ai écrit le code, donc je ne sais pas exactement comment ça a été géré, mais je suis censé l'améliorer…

Merci d'avance.

Édit: Je ne devais pas être très clair sur le stockage des pointeurs, alors j'ai clarifié.

Salut,
Maitriser la politique de copie de tes objets : faire du RAII où tu le peux, rendre non copiable tout ce qui peut l'être, et expliciter la politique de copie là où tu ne peux rendre non copiable.
Voilà les premières idées qui me viennent.

Je plussoie l'approche de 3D...

Je me demande d'ailleurs si je n'irais pas jusqu'à déclarer le destructeur de la classe de base manipulée par la classe qui doit gérer la durée de vie des objets polymorphes, et à déclarer cette dernière comme amie de la première :P

Cela pourrait limiter fortement les risques de tentatives de double libération ;)

Bonjour,
Étant de nature parano, je met assez systématiquement des conteurs d'objets.
Cela me permet de vérifier - au moins - que la mémoire est correctement désallouée.
J'utilise une classe template count... dont je dérive les classes que je souhaite vérifier

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template<class T> count { protected: count(){++count_;} virtual ~count{--count_;} private: static int count_; };   template<class T> int count<T>::count_ = 0;

---

Ça casse pas deux pattes à un canard, mais cela peut servir...

Citation:

---

Envoyé par koala01

Je me demande d'ailleurs si je n'irais pas jusqu'à déclarer le destructeur de la classe de base manipulée par la classe qui doit gérer la durée de vie des objets polymorphes, et à déclarer cette dernière comme amie de la première :P

---

Hum…
Pas sûr de comprendre où tu veux en venir… :roll:

Citation:

---

Envoyé par omc24

J'utilise une classe template count... dont je dérive les classes que je souhaite vérifier

---

Ça a l'air plutôt intéressant, mais je n'arrive pas à voir comment l'utiliser… :oops:

Bonjour,
Si tu veux vérifier une classe "A", tu n'as qu'à dériver cette classe de "count<A>" et cela fonctionne tout seul.
Comme le constructeur de count<A> ne prend pas de paramètre, tu n'as pas besoin de l'appeler depuis la zone d'initialisation des données membres du constructeur de A... Le compilo le fait pour toi.

Code:

---

1 2 3 4 5

class A : public count<A> { .... }

---

Citation:

---

Envoyé par Steph_ng8

Hum…
Pas sûr de comprendre où tu veux en venir… :roll:

---

en fait, j'aurais du dire: le destructeur de la classe de base / des classes abstraites protégé (virtuel) et ceux des classes dérivées / instanciables privées, en déclarant la classe responsable de leur durée de vie amie de toutes ces classes.

De cette manière, il n'y a que la classe responsable de la durée de vie qui est en mesure de détruire tes objets, c'est aussi simple que cela.

Si tu essaye, par inadvertance, d'invoquer delete sur un pointeur depuis "ailleurs que la classe amie", le compilateur se plaindra que le destructeur et privé dans le contexte, et sortira sur une erreur ;)

Mais cela n'est malgré tout possible qu'avec des hiérarchie d'ampleur limitée, et il faudra malgré tout veiller à ce que la classe responsable de la durée de vie de l'objet ne profite pas de l'amitié qui l'unit au dit objet pour aller jouer avec ce qu'elle ne devrait pas ;)

@omc24 Si j'ai bien compris, ça te sert à compter le nombre d'instantes d'une classe donnée.
Mais je ne vois pas comment l'utiliser en pratique, puisque ton compteur n'est pas accessible.
Et que se passe-t-il quand il arrive à 0 ?
Ou quand il n'arrive pas 0 à la fin du programme ?

@koala01 Ok, je crois que je vois mieux.
Enfin ça protège des doubles déallocations, mais pas des fuites mémoires.
Bon, c'est déjà pas mal. :)
C'est à la classe « amie » de s'occuper de bien libérer les ressources. ;)

@3DArchi Au fait, merci pour tes conseils.
J'avais déjà regardé rapidement la partie sur le RAII dans la FAQ il y a quelques temps, mais sans vraiment entrer dans les détails.
Je vais m'y replonger…

Au fait, quand une exception non interceptée est lancée, le programme est interrompu brusquement, non ?
Du coup, les objets, même statiques, ne sont pas détruits, si je ne m'abuse ?

Alors finalement, ça veut dire quoi « exception-safe » ?
« Sûr pour les exceptions capturées » ?

Si c'est bien le cas, j'ai du mal à voir comment les pointeurs intelligents permettent de se passer de vérifier que la mémoire a correctement été allouée.

De toutes manières, le système s'occupe (généralement plutôt bien) de "ramasser les miettes" de mémoire non libérées au moment où l'application est quittée, que ce soit sur demande de l'utilisateur ou suite à une erreur quelconque qui aurait provoqué le "plantage" de l'application.

L'exception safty a pour but de t'assurer, si une exception plus ou moins prévisible survient, que, si ton système est dans un état cohérent avant que l'exception ne survienne, il restera dans un état cohérent si l'exception est récupérée et traitée.

Mettons, simplement, que tu utilises une entrée utilisateur pour obtenir un nom de fichier à lire.

Ton programme est dans un état cohérent avant que tu ne tente de lire le fichier (ou du moins, nous supposerons que c'est le cas).

Mais, si l'utilisateur se trompe dans le nom du fichier, ou que le fichier est déjà "verrouillé" par le système, tu ne pourra pas l'ouvrir, et tu obtiendra une jolie exception.

La solution est, finalement, assez simple, et tu peux donc très facilement gérer ce genre de problème, et donc éviter que ton programme ne plante pour une telle c...rie.

En travaillant "exception safe", tu t'assure, si cette exception survient, soit l'ensemble des modifications apportées à l'état du programme seront annulées, soit que ton programme se trouvera dans un état cohérent en ayant appliqué un certains nombre de modifications qui seront prise en compte ;)

Citation:

---

Si j'ai bien compris, ça te sert à compter le nombre d'instantes d'une classe donnée.

---

Oui

Citation:

---

Mais je ne vois pas comment l'utiliser en pratique, puisque ton compteur n'est pas accessible.

---

Il suffit de rajouter un accesseur

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

template<class T> count { public: static int GetInstanceNumber(){return count_;} protected: count(){++count_;} virtual ~count{--count_;} private: static int count_; };   template<class T> int count<T>::count_ = 0;

---

Citation:

---

Et que se passe-t-il quand il arrive à 0 ?

---

Cela veut dire qu'il n'y à plus d'instance de la classe "A".

Citation:

---

Ou quand il n'arrive pas 0 à la fin du programme ?

---

C'est qu'il y a problème. Tous les objets n'ont pas été détruit. Ou alors, il y a des objets "statiques" qui seront détruit à la sortie du main() et dans ce cas c'est normal.

Citation:

---

Envoyé par omc24

Ça casse pas deux pattes à un canard, mais cela peut servir...

---

Ma réponse n'a rien d'informatique mais je la donne quand même :

On dit que ça casse pas trois pattes à un canard et pas deux pattes :mrgreen:

Citation:

---

Envoyé par MacPro

Ma réponse n'a rien d'informatique mais je la donne quand même :

On dit que ça casse pas trois pattes à un canard et pas deux pattes :mrgreen:

---

Que ferait-on sans les membres éclairés ?… :roll: :P

@koala01 Ok, je pense que j'ai à peu près saisi.
Merci ! ;)

Citation:

---

Envoyé par omc24

Citation:

---

Envoyé par Steph_ng8

Mais je ne vois pas comment l'utiliser en pratique, puisque ton compteur n'est pas accessible.

---

Il suffit de rajouter un accesseur

---

En fait, ça me paraissait évident ; mais vu que tu ne l'avais pas mis la première fois, je pensais que c'était voulu.

Citation:

---

Envoyé par omc24

Citation:

---

Envoyé par Steph_ng8

Et que se passe-t-il quand il arrive à 0 ?

---

Cela veut dire qu'il n'y à plus d'instance de la classe "A".

---

D'accord, ça j'avais compris.
Je voulais savoir s'il y avait une sorte de traitement automatique, ou s'il fallait s'occuper de la vérification à la main.
Je suppose que ça reste du manuel…

Citation:

---

Envoyé par omc24

Citation:

---

Envoyé par Steph_ng8

Ou quand il n'arrive pas 0 à la fin du programme ?

---

C'est qu'il y a problème. Tous les objets n'ont pas été détruit. Ou alors, il y a des objets "statiques" qui seront détruit à la sortie du main() et dans ce cas c'est normal.

---

C'est bien ce que je me disais.
Mais dans ce cas, il faut connaître le nombre d'objets statiques de portée globale ou égale à celle du main.
Bon ok, ce ne doit pas être très compliqué…