Graphe d'objet et désallocations
Bonjour, j'ai quelques problèmes de conception avec mon graphe d'objet et je me demande comment résoudre. Je me retrouve toujours avec des problèmes d'ordre d'initialisation ou de désallocation. J'esplik:
j'ai deux types d'objet: des ClassInfo (représentant des informations d'une classe que l'on peut demander au runtime) et des PropertyInfo (pour obteir des membres d'une instance)
les ClassInfo possèdent donc des PropertyInfo pour chaque membre.
De plus, les ClassInfo possèdent un membre parent, qui pointe sur le ClassInfo de la classe parent.
Je dispose dans ma boîte a outil de deux types de pointeurs intelligent: les ref<XXX> qui sont des pointeurs avec un refcount, et les weak<XXX> qui ne prolongent pas la vie de l'objet.
Le destructeur des classes renvoie une assertion si l'on désalloue un objet qui a encore des références faibles dessus; c'est a dire qu'avant de désallouer d'un objet il faut vérifier qu'il n'y a plus aucune référence weak dessus (dangling pointer). Je ne souhaite pas du tout me débarasser de ce système.
Jusque là jespère que vous suivez encore :)
Bon ensuite les PropertyInfo contiennent leur type, pour simplifier le ClassInfo qui représente la classe.
par exemple:
Code:
1
2
3
4
5
6
7
8
9
| class A
{
};
class B
{
public:
A a;
}; |
on aura donc ici:
un classinfo pour A
un classinfo pour B qui contient
un propertyinfo pour a qui utilise le classinfo de A
Le problème c'est que le graphe d'objet qui est donc un graphe représentant la structure du code, a des cycles et autres joyeusetés qui le rendent difficile a créer.
Par exemple, on peut avoir cela:
(oui parce que les pointeurs sont autorisés quand même)
on se retrouve donc avec un ClassInfo A, qui possède un PropInfo a, qui pointe de nouveau sur A.
Alors ma première expérience a donc été que le ClassInfo "possède" les propinfo, et qu'ensuite le propinfo a une référence faible sur le ClassInfo.
Cela résout les cycles (et il ne peut pas y avoir de cycles entre les classes donc ca marche, puisque l'héritage est un arbre)
Pan! problème résolu :)
Et ben non :( dans le cas:
Code:
1
2
3
4
5
6
7
8
9
| class A
{
};
class B
{
public:
A a;
}; |
il se peut très bien que A soit détruit avant B. La proprieté a sera donc detruite en même temps que B. Mais si A est detruit avant la propriété a, alors le PropInfo va se plaindre que son type est en train d'être désalloué :(
En gros soit j'ai un cycle et donc un leak mémoire, soit les PropInfo pointent sur des objets décédés. Je n'arrive pas trop a résoudre ca correctement :( any help welcome
Pour info, les ClassInfo et PropInfo sont extrait par un script python, qui parse les sources C++ et génère un autre fichier C++ qui contient les définition des classes. J'ai donc un bon contrôle du code et ca peut être compliqué puisque c'est automatiquement généré.
