Discussion :

[Spartx]

Merci de ton aide !

Si j'ai bien compris, tu proposes de faire une interface connue de la DLL et du client, soit implémentée dans les 2 entités.

Cela ne serait-il pas plus simple, et plus efficace, de directement mettre les classes nécessaires dans une autre DLL, liée dynamiquement à la DLL-carte et au client ? Ceci permettrait à mon avis une meilleure souplesse d'implémentation : il ne serait plus nécessaire de faire hériter toutes les classes nécessaires à l'interface, et donc de leur donner une "structure commune" ?

Pour ce qui est des "langages script", j'ai peur de non seulement ne pas pouvoir remédier à mon problème (utiliser librement les classes déjà compilées du client), mais aussi tomber sur des problèmes de sécurité. De plus, je n'ai encore jamais travaillé avec Python... (Lua n'étant pas orienté Objet, si j'ai bien compris)

[Joel F]

y a pas e miracle, les systemes d'event sont bases sur des choses predefini car le code du moteur doit permettre de repondre a un evenement en sautant dans un handler potentiellement enregistré.

Et j'abonde dans le sense de 3DArchi, un moteur de script suffit largement pour ces choses la et si LUA est orienté objet.

[3DArchi]

Salut,

Si j'ai bien compris, tu proposes de faire une interface connue de la DLL et du client, soit implémentée dans les 2 entités.

Cela ne serait-il pas plus simple, et plus efficace, de directement mettre les classes nécessaires dans une autre DLL, liée dynamiquement à la DLL-carte et au client ? Ceci permettrait à mon avis une meilleure souplesse d'implémentation : il ne serait plus nécessaire de faire hériter toutes les classes nécessaires à l'interface, et donc de leur donner une "structure commune" ?

C'est quand même une des bases de l'orientée objet : l'abstraction permet de découpler les classes entre elles. Les liens se font vers des classes 'abstraites' dont le comportement effectif est implémenté dans les classes concrète dérivées.

Ne penses-tu pas que la lecture d'un livre/article sur l'architecture orienté objet pourrait t'aider ?

Pour ce qui est des "langages script", j'ai peur de non seulement ne pas pouvoir remédier à mon problème (utiliser librement les classes déjà compilées du client), mais aussi tomber sur des problèmes de sécurité. De plus, je n'ai encore jamais travaillé avec Python... (Lua n'étant pas orienté Objet, si j'ai bien compris)

Le scripting comme Python et Lua devrait assez efficacement répondre à ton problème. Et intuitivement je dirais qu'il pose moins de problème de sécurité car l'interpréteur est probablement mieux protéger contre les erreurs/malveillances potentiels qu'un code que tu ferais from scratch.

[Spartx]

C'est quand même une des bases de l'orientée objet : l'abstraction permet de découpler les classes entre elles. Les liens se font vers des classes 'abstraites' dont le comportement effectif est implémenté dans les classes concrète dérivées.

Ne penses-tu pas que la lecture d'un livre/article sur l'architecture orienté objet pourrait t'aider ?

Je suis d'accord sur ce point, cependant, il est toujours vivement recommandé de ne pas abuser de l'héritage ; ici, les classes susceptibles d'être utilisées par la DLL et le client auront un comportement complètement différent, tout comme le nombre de fonctions utiles aux 2 entités ! Je pense que l'utilisation d'interfaces dans ce cas risquerait grandement de limiter voire bloquer l'implémentation de mes classes.


Je vais me pencher du coté du scripting qui, effectivement, a l'air intéressant.

Quoi qu'il en soit, merci à tous pour votre aide et vos conseils !
Bonne journée

[loufoque]

Tu peux remplacer le code du fonction par une autre à l'édition de liens, si ça t'amuse (en supposant que celle-ci n'est pas été inlinée).
Certaines personnes s'en servent pour remplacer malloc ou chose de ce type, mais c'est pas fondamentalement différent que d'avoir une interface de DLL propre.

C'est ce qu'il a de plus proche de ce que tu demandais originellement.

[Emmanuel Deloget]

Ah, pour ceux qui doutent encore des capacités qu'on a, pauvres développeurs que nous sommes, pour créer du code exécutable au runtime :

https://gna.org/projects/softwire/

Il ne faut jamais dire que quelque chose est impossible

[loufoque]

Générer du code qu'on recompile à la volée ou le multi-stage ça se fait très bien en C++ classique et ce n'est pas nouveau.

[Emmanuel Deloget]

Générer du code qu'on recompile à la volée ou le multi-stage ça se fait très bien en C++ classique et ce n'est pas nouveau.

Là je serais curieux d'en avoir un exemple.