Discussion :

[K007024]

Bonjour à tous,

Je n’écris pas souvent mais je passe souvent pour lire en guest. Voici ma petite question de codeur C++ du dimanche : comment puis-je copier une classe A dans une classe A’ « semblable » ?

Le contexte.

Je reprend une appli C++/wxWidget et je cherche à la rendre plugin-based pour pouvoir faire des upgrades en changeant une dll seulement.
J'ai actuellement une classe A qui fait lecture d'un fichier + stockage des données, les données sont complexes et ont necessité de définir quelques sous-classes pour le stockage. J'aimerais garder le classe A dans le soft pour le stockage des données mais j'aimerais sortir la partie lecture dans un plugin.

Ce que j'aimerais faire
Coller ma classe A dans mon plugin pour la lecture ("soft, tu lis et tu ranges les données dans une forme A") puis rappatrier les données dans mon soft pour les utiliser ("soft, tu copies l'objet A qui vient du plugin comme si c'était un objet A à toi et tu l'utiliseras comme ça").

Problématique
1/ J'ai des attributs avec des types custom (ma classe "A" contient des privates de type "B") qu'il faut que je ramene dans le plugin
2/ Si A==A (et B==B) au début, par la suite l'idée c'est que ça bouge : j'aurais du A, codé avec mes petits doigts et du A' codé par un tiers. Or je ne maitrise pas la copie des trucs un peu bizarre.



J'ai pensé aux derivées (tiens, si A et A' derivent de la meme classe, ça pourra peut etre marcher) mais j'ai un doute
J'ai pensé aux interfaces (mais je galère bien, j'ai découvert ça avec les plugins et je suis pas à l'aise du tout).

Une âme charitable pourrait elle m'aiguiller ?

Merci d'avance,
Julien K


Comment, le plus simplement possible, vous feriez pour faire un truc du genre : maClasseCustomA=maClasseCustomABidouilléeParUnTier ?

[bacelar]

faire des upgrades en changeant une dll seulement.

C'est donc que pour Windows ?

je cherche à la rendre plugin-based

Le compilateur de la Dll ou sa configuration est donc potentiellement différent de l'exécutable => Oubliez toutes notions de classe ou d'allocation dynamique !!!

Vous n'êtes pas très claire sur comment vous pensez faire évoluer A ou A' et quoi/comment partager les définitions communes aux Plug-Ins et à l'exécutable.
Il est impératif que vous puissiez répondre à ces questions.

Séparer le "stockage" et la lecture du fichier, c'est un découpage contre naturel.
Le découpage bien plus naturel est d'avoir une classe qui est capable de lire le fichier et de construire un objet correspondant. Cet objet devant respecter une interface imposé par l’exécutable.

Nous sommes bien d'accord que vous voulez faire une architecture de plug-Ins pour Mickey?
Sinon, oubliez les classes C++ et rabattez-vous sur le C et ses conventions d'appel.

Alors, pour faire un truc de Mickey, vous définissez dans votre exécutable une classe de base A, abstraite, et vos plug-Ins n'auront qu'à dériver cette classe et fournir une instance de cette classe dérivé. Comme c'est du MickeyLand (même compilateur, même configuration,...) le layout mémoire de la classe dérivée sera compatible avec celui de la classe de base.

[K007024]

Bonjour,

Tout d'abord merci pour la réponse.

Je suis effectivement à Mickey Land : OS et compilateur bloqué (je spécifie) et le soft doit pouvoir être repris par un tiers qui sera à Iso-configuration + sources et documentation dispo. C'est un proto maison dont j'herite et sur lequel je dois faire 2-3 upgrades.

Dans ces upgrades il y a "le rendre modulaire" (refaire l'archi) et sortir les méthodes de lecture de fichier pour pouvoir lire d'autres fichiers par la suite. Ça c'était OK (même si j'ai un peu galeré vu mon niveau...)

L'idée est donc bien de lire des fichiers et de les ramener à une forme normalisée utilisable part l'exécutable.

Je pensais donc
1/ Lire le fichier et le mettre en forme "standard" dans le plugin
2/ Récupérer cette forme standard dans l'exécutable pour le traiter comme ça à toujours était fait (manipulation, affichage)


Je vais suivre votre conseil et creuser les interfaces.

[white_tentacle]

Le compilateur de la Dll ou sa configuration est donc potentiellement différent de l'exécutable => Oubliez toutes notions de classe ou d'allocation dynamique !!!

Ou pas. C’est raisonnable de forcer que la dll soit compilée avec le même compilateur (ou, du moins, la même ABI) que le programme principal. Pour les allocations dynamiques, il faut juste s’assurer que :
- la mémoire allouée par la dll est libérée par la dll
- la mémoire allouée par le programme principal est libérée par le programme principal

En gros, pas de transfert de propriété d’objets entre le programme et la dll, et effectivement, dans l’interface, il faut que les objets utilisés aient une ABI stable (ce n’est pas forcément le cas des objets de la lib standard C++, à vérifier au cas par cas).

Séparer le "stockage" et la lecture du fichier, c'est un découpage contre naturel.
Le découpage bien plus naturel est d'avoir une classe qui est capable de lire le fichier et de construire un objet correspondant. Cet objet devant respecter une interface imposé par l’exécutable.

Je m’inscris en faux contre ça. Séparer le stockage et la lecture est une très bonne pratique, ça permet de changer de format de fichier assez facilement, voire de construire une même structure depuis plusieurs formats différents, ou de construire des structures différentes à partir du même fichier (par exemple, une structure au layout optimisé pour le traitement qui va suivre). Pour prendre une analogie avec XML, ce que tu recommandes c’est DOM, moi je lui préfère SAX. La partie « lecture » et la partie « construction de l’objet » sont séparées en SAX.

Nous sommes bien d'accord que vous voulez faire une architecture de plug-Ins pour Mickey?
Sinon, oubliez les classes C++ et rabattez-vous sur le C et ses conventions d'appel.

Ces trucs de Mickey fonctionnent quand même en prod, à condition de faire attention à ce qu’on fait. Qt fournit par exemple un mécanisme de plugins comme ça. Se limiter à du C, c’est un peu extrême comme solution.

[K007024]

Bonjour,


Juste pour répondre et donner la solution que j'ai choisi de mon coté.

La DLL embarque la classe definissant le stockage de ma donnée (la même que dans le soft principal).
L'utilisateur lit le fichier comme il veut et "range" dans la classe de stockage (i.e. format imposé).

Je transmet ensuite la classe principale de la partie DLL à la partie soft principal.


(désolé pour les puristes, ce n'est pas un langage très rigoureux)

Résolu.