IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Gestion d'exceptions et plugins


Sujet :

C++

  1. #1
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2010
    Messages
    517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Santé

    Informations forums :
    Inscription : Avril 2010
    Messages : 517
    Points : 718
    Points
    718
    Par défaut Gestion d'exceptions et plugins
    Bonjour tout le monde!

    J'essaye actuellement de mettre en place la gestion d'exception au sein de mon application. Celle-ci est diviser en 3 parties:
    • La bibliothèque coeur (une dll)
    • L'interface graphique (écrite en Qt)
    • Les plugins (une dll par plugin)


    Le coeur et les plugins ne dépendent pas de Qt (et ne doivent pas en dépendre). La GUI et les plugins dépendent du coeur.

    Le but est tout simplement de récupérer les exceptions lancées par les plugins et les afficher dans la GUI.

    Je me suis donc dis pourquoi pas faire un singleton et un observable qui gère les exceptions au niveau de mon coeur qui me permettra de lancer les exceptions à tous les observateurs attachés.
    Côté GUI, j'ai créé un widget qui demande en entrée le message d'erreur et récupère l'état de sortie (si on veut continuer l'exécution du plugin ou pas).
    Toujours, côté GUI, j'ai créé un observateur qui observe mon singleton et créé mon widget à chaque fois que la méthode notify() de mon singleton/observable est appelé. Cet observateur est instancié lors de la création de mon interface graphique.

    Le problème, c'est que la mémoire entre mon interface graphique et mes plugins n'est pas partagée donc lorsque j'appelle mon singleton dans un plugin, j'obtiens une autre instance que celle présente dans ma GUI.

    J'ai regardé un peu du côté de la mémoire partagée mais je n'y connais rien du tout.

    Est-ce que quelqu'un aurait une solution (pas trop os-dépendant si possible)?

    Merci d'avance!

    PS: J'ai pensé à passer en paramètre une instance de ma gestion d'exception lors de l'appel des plugins, mais il faudrait modifier tous les squelettes des fonctions... Donc si je peux éviter, ça serait parfait

  2. #2
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Citation Envoyé par darkman19320 Voir le message
    Le problème, c'est que la mémoire entre mon interface graphique et mes plugins n'est pas partagée donc lorsque j'appelle mon singleton dans un plugin, j'obtiens une autre instance que celle présente dans ma GUI.
    Tu as la réponse dans la question, il ne faut pas utiliser un singleton .

    Ici, si tu as bien besoin de l'unicité de l'instance, rien ne justifie son accessibilité globale, puisque son usage n'a de sens que pour les plugins et l'interface. Le code coeur devrait communiquer à l'interface et aux plugins l'objet à utiliser et doit s'occuper de gérer son cycle de vie, et en assurer l'unicité... simplement en ne l'instanciant qu'une fois.
    Find me on github

  3. #3
    Membre émérite
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    2 764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 2 764
    Points : 2 704
    Points
    2 704
    Par défaut
    Citation Envoyé par jblecanard Voir le message
    Ici, si tu as bien besoin de l'unicité de l'instance, rien ne justifie son accessibilité globale, puisque son usage n'a de sens que pour les plugins et l'interface. Le code coeur devrait communiquer à l'interface et aux plugins l'objet à utiliser et doit s'occuper de gérer son cycle de vie, et en assurer l'unicité... simplement en ne l'instanciant qu'une fois.
    On se retrouve tout de même parfois à trimballer sur tout le programme une référence d'instance dans un appel de fonction sur deux...

  4. #4
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Salut

    Citation Envoyé par oodini Voir le message
    On se retrouve tout de même parfois à trimballer sur tout le programme une référence d'instance dans un appel de fonction sur deux...
    On va pas refaire le débat sur le billet d'Emmanuel ici. Dans ce cas précis, ça ne devrait pas se produire:
    • Dans le cas des plugins, ceux-ci sont sûrement déjà gérés par un manager qui peut exposer l'observateur.
    • Dans le cas des widgets de la GUI, ils ont toujours au moins un parent (qui permet de remonter au parent racine), au mieux un accès à un gestionnaire central.


    On peut exposer l'observateur dans ces deux objets sans qu'il y ait besoin de trimbaler la référence partout.
    Find me on github

  5. #5
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2010
    Messages
    517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Santé

    Informations forums :
    Inscription : Avril 2010
    Messages : 517
    Points : 718
    Points
    718
    Par défaut
    Merci pour ces réponses.

    Citation Envoyé par jblecanard Voir le message
    Ici, si tu as bien besoin de l'unicité de l'instance, rien ne justifie son accessibilité globale, puisque son usage n'a de sens que pour les plugins et l'interface. Le code coeur devrait communiquer à l'interface et aux plugins l'objet à utiliser et doit s'occuper de gérer son cycle de vie, et en assurer l'unicité... simplement en ne l'instanciant qu'une fois.
    Justement, j'aimerai éviter de changer l'interface de mes plugins qui sont assez nombreux (environ 200).

    Citation Envoyé par oodini Voir le message
    On se retrouve tout de même parfois à trimballer sur tout le programme une référence d'instance dans un appel de fonction sur deux...
    Exactement, pour le moment il n'y a qu'un seul plugin qui gère les exceptions et je ne suis pas certain que dans un avenir plus ou moins proche, les plugins restants vont les gérer...


    De plus, je viens de tester mon code sous linux et OS X et il fonctionne parfaitement... La gestion de la mémoire sous Windows est complètement différente? (Une pile par dll?)

  6. #6
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Salut

    Si ça fonctione sur Linux et MaxOS, je suppose que tu as linké en statique. Il ne s'agit pas de modifier l'interface des modules mais l'interface de leur manager, pour rajouter un accesseur sur l'observateur par exemple. C'est pas gaulé comme ça dans ton code ?
    Find me on github

  7. #7
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2010
    Messages
    517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Santé

    Informations forums :
    Inscription : Avril 2010
    Messages : 517
    Points : 718
    Points
    718
    Par défaut
    J'ai bien linké en dynamique sous MacOS et Linux.

    Et malheureusement, il n'y pas de manager "évolué" (encore) dans le code. Juste le chargement des plugins au début du lancement de l'application puis le chargement d'une fonction lors de l'appel d'un d'eux qui prend en entrée des listes de void*..... (La reprise de code est toujours assez difficile ^^) Je pourrais caster mon observateur en void* mais bon c'est pas trop top non plus comme solution, non?

    Je comprends tout à fait que le singleton pose problème. Surtout si je lance plusieurs fois mon application mais bon vu que c'est une application 3D qui demande beaucoup de ressources, il est rare d'avoir (et surtout de pouvoir) la lancer en simultanée.

    Je vous attache un petit exemple simplifié de ma gestion des exceptions.

    pluginmanager.zip

    Il se compose de trois parties: Application, Core et PluginA. J'ai fait un script CMake pour faciliter la compilation. Le but est d'obtenir deux messages d'erreur: le premier par la récupération de l'exception à partir de la méthode run du pluginA, le second par envoie de mon exception vers mon observateur/singleton.

    C'est un code écrit assez rapidement donc il y a encore pas mal de boulot à faire mais il fonctionne bien sous Linux et Mac. Par contre sous windows, c'est une autre histoire...

    Edit: Je viens de réussir!! J'ai lu ce poste et j'ai donc décidé de simplement spécialiser ma fonction getInstance au niveau de mon observateur/singleton et magique ça fonctionne!!
    Je mets résolu mais j'aimerai bien comprendre le pourquoi du comment...

    Merci pour tout!

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Gestion des exceptions avec le plugin ErrorHandler ?
    Par AzAt0th dans le forum Zend Framework
    Réponses: 7
    Dernier message: 07/01/2008, 15h31
  2. Gestion des exception (EOleException)
    Par shurized dans le forum Bases de données
    Réponses: 5
    Dernier message: 30/06/2004, 18h25
  3. [C#] Gestion d'exception
    Par ALCINA dans le forum Windows Forms
    Réponses: 4
    Dernier message: 18/05/2004, 13h18
  4. [XMLRAD] gestion des exceptions
    Par pram dans le forum XMLRAD
    Réponses: 2
    Dernier message: 28/01/2003, 18h48
  5. c: gestion des exceptions
    Par vince_lille dans le forum C
    Réponses: 7
    Dernier message: 05/06/2002, 15h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo