Discussion :

[Steph_ng8]

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

[3DArchi]

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.

[koala01]

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

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

[omc24]

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 :

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

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

[Steph_ng8]

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

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

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…

[omc24]

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 :

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

1
2
3
4
5
 
class A : public count<A>
{
....
}

[koala01]

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

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

[Steph_ng8]

@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…

[Steph_ng8]

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.

[koala01]

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

[omc24]

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

Oui

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

Il suffit de rajouter un accesseur

Code :

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

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;

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

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

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.

[MacPro]

Ç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

[Steph_ng8]

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

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

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

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

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…

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é…