Titre complet : Gestion de la suppression d´instance de classe. (c´est un bug de la nouvelle version de JV, que le champ de texte sur la page principal du forum n´est pas limité en nombre de caractères)

Voila mon problème : Je suis entrain d´écrire une bibliothèque (plus pour l´exercice que pour autre chose) de gestion d´expression arithmétique sous forme d´arbre.

Donc chaque expression peut s´appliquer à 0, 1 ou 2 opérandes qui s´évaluent récursivement lorsque c´est nécessaire.
Et chaque operandes à un operande "père" (sauf la racine de l´expression).

Donc globalement lorsque le père est détruit il delete aussi tout ses opérandes fils (ce qui est ennuyeux s´ils ont été créé par le compilo, mais j´arrangerais ça après).

Mais pour optimiser le logiciel et pour gagner du temps de calcul je me suis dit qu´il faudrait qu´un opérande puisse avoir plusieurs père, comme celà, si une même expression intervient plusieurs fois dans un calcul, on ne l´évalue qu´une seul fois. Mais le problème est donc que l´opérande ne doit pas forcément être détruit lorsque son père est détruit. Alors bien sur le père peut demander à l´opérande s´il a d´autre pères avant de le détruire mais ce n´est pas très propre.
Alors est ce qu´il est possible pour une class dans son destructeur, d´annuler sa destruction, c´est à dire de s´arranger pour que même à l´issue de l´exécution du destructeur, un pointeur vers cette classe soit toujours valide.

Sinon l´autre possibilité sera que l´on ajoute et retire des père à la classe et que celle ci s´autodétruise lorsque l´on a retiré le dernier père, ce qui n´est pas très satisfaisant non plus, car on peut vouloir la conserver.

Au passage, je viens de découvrir l´utilité d´une fonction virtuel, je crois que c´est le dernier bout fondamental (il doit rester des trucs moins important que je ne connait pas) des principes de la POO du C++ qui me manquait.

Ou sinon tu peux utiliser les smart pointers, enfin les counted pointers. Ainsi la destruction d´un object contenu a divers endroit ne se fera que lorsqu il ne sera plus reference.

Alors est ce qu´il est possible pour une class dans son destructeur, d´annuler sa destruction, c´est à dire de s´arranger pour que même à l´issue de l´exécution du destructeur, un pointeur vers cette classe soit toujours valide.

Nope, enfin pas a ma connaissance

/kUfa

yep, ca sens le comptage de references tout ca..

Tu peux encapsuler et faire par ex. des Release() sur tes interfaces (a la facon COM), plutot que les detruire explicitement.

approche un peu differente : une classe (eventuellement un template) avec les ressources en statique. Tu incrementes/decrementes un compteur d´instances dans les ctor/dtor, et tu n´alloues/detruit les-dites ressources que quand le compteur passe de 0 a 1, et 1 a 0.
T´as l´avantage de contruire et detruire tes objets comme a l´habitude, et celui de la consommation de ressources reduites, si elles peuvent etre partagees. Par contre il est plus dur de partager des objets, vu que tu continues a en construire/detruire a la volee.

au passage pour aider dans certains cas t´as toujours le "delete this" ; tres efficace pour faire des objets autonomes, qui gerent eux meme leur duree de vie. Il faut juste etre sur de ce qu´on fait avec le code appelant de tels objets.

Alors est ce qu´il est possible pour une class dans son destructeur, d´annuler sa destruction, c´est à dire de s´arranger pour que même à l´issue de l´exécution du destructeur, un pointeur vers cette classe soit toujours valide.

Nope, enfin pas a ma connaissance

pareil ; tu peux toujours ruser a coup de placement new + appel explicite de destructeurs, pour "reutiliser" les zones memoires ; mais pour cela il faut des donnees membres assez particulieres avec des constructeurs qui surtout ne font rien. => pas propre, cas extremes.. (c´est un peu comme des casts en memoire partagee quoi)
par contre, a titre informatif, on peut "aborter" un constructeur avec une exception ; l´exception pouvant ne pas etre qualifiee, un bete throw faisant l´affaire. Bon c´est pas super propre et generalement on utilise pas les exceptions, mais comme je dis, c´est juste a titre informatif

je pense que je vais essayer de voir du coté des compteur. Ca m´a l´air le plus logique, même si c´est pas évident (que ce soit le plus logique, vu que dans certain cas, le compteur peut passer à zéro et je peut avoir envie de garder l´objet).

a ce moment la, tu peux utiliser des compteurs PLUS un mechanisme de recyclage ; quand un objet doit etre detruit, ben tu le detruits pas vraiment : tu le fous dans une "recycle bin".
Si la poubelle est pleine, tu delete vraiment les elements les plus anciens.
Quand tu veux creer un nouvel objet, tu regardes d´abord dans la poubelle si un objet du meme type peut etre recycle. ; sinon tu crees un vrai nouvel objet. C´est un peu comme un cache.
´te reste plus qu´a tweaker la taille de cette poubelle pour obtenir un bon compromis resources/efficacite.

au passage, si tu templatises ce mechanisme, ca devient tres facile a ajouter sur des nouvelles classes.

Va aussi voir du cote des freelists. Au passage, au lieu de partager les objets, tu pourrais avoir l´approche inverse, a savoir seulement qq objets qui partagent leurs donnees communes mais pas leur specificites. C´est le principe du design pattern FlyWeight.

Lorsque tu écris "Donc chaque expression peut s´appliquer à 0, 1 ou 2 opérandes qui s´évaluent récursivement lorsque c´est nécessaire"

Tu comptes utiliser un arbre binaire ?

Sinon quelle est aussi la probabilité pour qu´un opérande soit utilisé plusieurs fois ? (j´en sais rien). Partant du principe que l´utilisateur sait ce qu´il fait, pourquoi ne pas luis donner l´occasion de déclarer lui même explicitement les portions d´expression qu´il souhaite garder en mémoire, à l´aide d´une commande spécifique ? Dans ce cas, il suffirait d´effectuer le nettoyage à la fin de chaque session de calcul (ou par l´appel d´une autre commande spécifique)

A mon avis la grosse optimisation qui pourrait être faite, c´est de passer d´un résolution récursive (non terminale en l´occurence) à une résolution itérative linéaire qui permettrait de supprimer toute la séquence d´appels en cascade induits par le récursif, en commencant par évaluer les noeuds qui occupent les niveaux supérieurs de l´arbre, pour redescendre ainsi jusqu´à la racine (je me sers de cette méthode pour mon évaluation de formules logiques avec une liste chainée, dont chaque noeud représente un niveau de l´arbre, contenant une liste des noeuds de l´expression occupant le niveau correspondant de l´arbre : on parcours la liste linéairement en partant du plus haut niveau, et on résoud chaque noeud, sachant qu´un noeud n´a besoin pour se résoudre que de l´état de ceux qui sont de niveaux strictement supérieurs et que les feuilles de l´arbres sont définies).

utilise les counted pointers

En fait, le problème de ma méthode vient de fait que chaque opérande doit être créer dynamiquement vu la manière dont ils sont géré.
Donc en fait je ne prévoit pas de mettre à la disposition de l´utilisateur de méthode pour contruire un arbre.
Par contre je pense créer une fonction qui convertira une expression arithmétique en arbre. Et ensuite l´utilisateur pourra (peut-être) manipuler l´arbre.

L´idée étant que si par exemple certain des opérandes sont des variables (pour l´instants, elles doivent forcément avoir une valeurs numériques) et que leur valeurs est modifié celle les noeuds modifié sont réévalué et les autres conservent leur valeur pour accélérer le calcul.