Utilisation de classes d'une shared library dans mon application principale.

Bonjour,

J'ai un programme en C++ sous linux qui utilise une librairie dynamique. Après le chargement de ma librairie j'appelle une fonction d'initialisation qui crée des objets et les ajoute à un conteneur de mon application principale. Ces objets de type AA dérivent d'une classe de mon appli A.

A <- AA

Application :
conteneur.add(new A());

Librairie :
conteneur.add(new AA());

Lorsque je vide mon conteneur et que je supprime mes objets de type AA j'ai un segmentation fault. Après quelques recherches sur le net j'ai trouvé cet article qu'il faut passer par des fonctions create_object et destroy_object pour allouer ou supprimer des objets d'une shared library.

Ma question est de savoir pourquoi il faut passer par ces fonctions? Comment fonctionne exactement l'allocation/desallocation d'objets et l'appel de fonctions dans une shared library?

Moi je serais toi, je vérifierai :

1. est-ce que j'ai bien mis un déstructeur virtuel dans A?
2. est-ce que je ne me retrouve pas dans un cas ou je tente de deleter un objet qui l'est déjà? vérifier les algorithms gérant els objets, faire du log ou du breakpoint.


Enfin, si tes mémoires ne sont pas partagées entre dlls et application, il faut que le new et le delete soient fait dans le même module. Sinon tu peux avoir des surprises.

Citation:

---

Envoyé par Klaim

1. est-ce que j'ai bien mis un déstructeur virtuel dans A?

---

Le destructeur est bien virtuel.

Citation:

---

Envoyé par Klaim

2. est-ce que je ne me retrouve pas dans un cas ou je tente de deleter un objet qui l'est déjà? vérifier les algorithms gérant els objets, faire du log ou du breakpoint.

---

Les objets sont bien supprimé qu'une seule fois. J'ai fait un petit programme de test qui fonctionne si je fais les new et delete dans la lib et crash si je fais un new dans la lib et delete dans l'appli.

le new et le delete doivent etre soit les deux dans l'appli, soit les deux dans la library, car une shared library a son propre espace de mémoire.

Exactement, c'est ce que je voulais dire par

Citation:

---

Enfin, si tes mémoires ne sont pas partagées entre dlls et application, il faut que le new et le delete soient fait dans le même module. Sinon tu peux avoir des surprises.

---

(paceque pour moi l'appli est un module "maitre")

Dans tous les cas, globalement la technique pour résoudre ce probleme consiste à

1. mettre en place une ou plusieurs fonctions dont l'application connait le nom et la signature mais qui sont implémentés dans chacun des modules externes (dlls)
2. cette fonction fournis des factory (objets ou fonction) qui servent a créer les objets issus du module mais avec des interfaces connues de l'application.

Les détails dépendent totalement du de communicatino entre application et modules. Si tu veux des idées, jettes un oeil à comment boost.extension (pas encore dans boost) fonctionne conceptuellement : http://boost-extension.redshoelace.c...ion/index.html