c++, fonction modifiable après compilation

Version imprimable

12/08/2011, 14h15
Spartx

c++, fonction modifiable après compilation

Salutations !

Avant toute chose, je m'excuse pour le nom du sujet... Difficile de trouver un titre qui explique vraiment en quelques mots ce que je recherche !

En bref, j'aimerais savoir s'il existait un moyen simple de faire des fonctions (ou classes) qui puissent être modifiées après la compilation de mon programme.

La première solution qui viendrait à l'idée serait l'utilisation de DLL. Cependant, je souhaiterais que le code modifié soit complètement interactif avec le programme ! En clair, il faudrait que les fonctions placées dans la DLL puissent interagir directement avec des éléments de l'exécutable.
Je pensais qu'il y avait quelque chose à faire en combinant le "dllexport" avec le "dllimport", mais je ne parviens pas à l'utiliser correctement et à en faire ce que je souhaite ici... (Si c'est la solution, pourrait-on m'expliquer comment il fonctionne svp (j'ai recherché des multitudes d'exemples sur le net, mais aucun n'a été assez complet à mon goût pour vraiment m'aider...))

Je vous remercie d'avance pour votre aide !
12/08/2011, 15h14
oxyde356

Oui les DLL conviennent dans ton cas si ce que tu veux c'est pouvoir changer la définition (juste le corps) d'une fonction sans avoir à toucher à ton programme. Tu trouveras plein de tutos de qualités sur le sujet en cherchant sur google ou sur la FAQ de ce site qui contient une rubrique sur les DLLs.
12/08/2011, 16h46
3DArchi

Salut,
La première chose qui me vient à l'idée c'est qu'il ne s'agit pas d'un problème de dllimport ou de dllexport mais un problème d'architecture logiciel : identifier les bonnes interfaces, les bons DP, les bons points de variations, etc....
12/08/2011, 16h58
Obsidian

Bonjour,

Citation:

Envoyé par Spartx

En bref, j'aimerais savoir s'il existait un moyen simple de faire des fonctions (ou classes) qui puissent être modifiées après la compilation de mon programme.

Dis-nous exactement ce que tu aimerais faire au final, ce sera beaucoup plus clair. Tu ne pourras pas réellement « modifier » dynamiquement et a posteriori le code de ton programme puisque c'est justement le but de la compilation. Par contre, tu peux faire en sorte que tes fonctions appellent différentes routines en fonction du contexte à l'exécution.

Le plus simple est encore un gros switch principal dans le corps de ta fonction, mais tu peux également utiliser les pointeurs de fonction comme démontré dans cette discussion sur le forum C.

Si par « modifier », tu entends « les mettre à jour », effectivement, l'utilisation de DLL est ce qu'il y a de plus indiqué.
12/08/2011, 17h44
Spartx

Merci à tous pour vos réponses ! :p

Je vais être plus clair sur ce que je cherche à faire ; cela vous aidera peut être à m'aider ! :roll:

En fait, je souhaiterais, dans un but pédagogique, concevoir un mmorpg.
La seule difficulté que je n'ai pu réellement surmonter est celle de la gestion des cartes : celles-ci doivent être fréquemment mises à jour.

La difficulté est que j'ai choisi de coder les évènements directement sur chaque carte ; et c'est pour cela que j'avais axé mon étude sur les DLL.

En théorie, j'vais pensé à cette architecture :
[DLL contenant les données de la carte et quelques évènements (à faible sécurité)] <==> [client du jeu]
Le problème ici est que la DLL ne peut utiliser des classes définies dans le client ! C'est pour cela que j'ai cherché du coté du dllimport pour définir ces classes dans la DLL sans en refaire l'implémentation.

Dans le cas où la seule solution serait effectivement du côté des dllimport et dllexport, serait-il possible d'avoir un petit exemple simple d'utilisation svp ? J'ai consulté moultes tutoriaux, mais à chaque fois, si l'explication quant au dllexport est complète, celle du dllimport n'est abordée que trop brièvement et je m'y perds... :s

Merci d'avance !
12/08/2011, 17h50
screetch

en général un jeu est une sorte de moteur qui interprète et affiche des données, et ce sont les données qui donnent le comportement du code.

Les données permettent donc d'agir sur le comportement du jeu, qui réagit selon que l'on a affaire a un troll ou a une tapette d'elfe (oops pardon c'est sorti tout seul)
on essaye de tendre vers le moins possible de code, le plus possible de données =)

les données ne sont jamais dans une DLL :)
12/08/2011, 18h02
Spartx

Seulement, il ne s'agit pas directement de données de jeu, mais d'évènements propres à la carte dans laquelle ils s'inscrivent !

Dans la plupart des éditeurs de jeu que l'on peut trouver sur le net, les évènements (tant la condition que l'effet) sont pré-établis, ce qui, à mon goût, limite grandement les possibilités du jeu.
L'idée serait donc de faire appel à des scripts évènementiels pour maximiser les possibilités. C'est pour cela que j'ai pensé qu'il serait efficace de garder une partie "programmation" propre à chaque map.
J'ai d'ailleurs jeté un bref coup d'oeil aux langages de script s'interfacant à c++ (Lua / Boost::Python ...), mais le problème reste le même : impossible de faire appel à des données internes au client (la fenêtre de sortie, par exemple).
12/08/2011, 18h19
Obsidian

Donc, en gros, ce que tu veux faire, c'est un système de « plug-in ».

— Effectivement, c'est très courant ;
— Effectivement, ce n'est pas trivial du tout.

La difficulté va résider d'une part dans le fait de définir à l'avance des interfaces à la fois propres et suffisamment versatiles pour te permettre d'implémenter ce à quoi tu n'as pas encore pensé et, d'autre part, d'éviter les failles de sécurité, notamment quand tu les distribueras (système de signature).

Il peut être salutaire, dans ce cas, de concevoir à l'avance plus systèmes d'intérêt général qui te permettent d'emblée de faire 99% du travail, pour éviter d'avoir à recourir à du code par la suite. Par exemple, l'intelligence artificielle qui régit le comportement des PNJ s'appuie elle-même sur une base de connaissances. Si ton I.A. est suffisamment polyvalente à la base, il te suffira la plupart du temps de mettre à jour cette base.

Autrement, la plupart des « add-on » commercialisés sont souvent des applications à part entière, avec processus d'installation etc. qui, une fois lancées, s'interfacent avec les logiciels déjà en place.

Donc, pour résumer, c'est avant tout un problème de conception en amont et de distribution ensuite. Entre les deux, sur le plan technique, les plug-in prennent généralement la forme de DLL chargées a posteriori par l'application exécutée, comme tu l'as suggéré. C'est le cas des modules Apache, par exemple.
12/08/2011, 18h33
Spartx

Citation:

Envoyé par Obsidian

La difficulté va résider d'une part dans le fait de définir à l'avance des interfaces à la fois propres et suffisamment versatiles pour te permettre d'implémenter ce à quoi tu n'as pas encore pensé et, d'autre part, d'éviter les failles de sécurité, notamment quand tu les distribueras (système de signature).

Je ne comprends pas trop... Le but de mon système est justement d'éviter cela !
Lors de l'implémentation classique pour ce genre d'évènements, où toutes les possibilités sont déjà prédéfinies, il faut effectivement tout prévoir dès le début ; mais dans mon cas, où je souhaite définir mes évènements dans des DLL, pourquoi serait-ce le cas ?
Je pensais simplement faire des procédures appelées à la création et à la suppression de la carte, et quelques fonctions qui réagiraient comme des "Listeners" (changement de coordonnées, pression d'un bouton, etc...).

Je souhaiterais vraiment établir mon système de carte afin qu'il me permette de tout faire sans avoir à retoucher à chaque fois le client lui-même. Dois-je, selon vous, abandonner l'idée de la DLL-carte ?
12/08/2011, 18h49
Obsidian

Citation:

Envoyé par Spartx

Je ne comprends pas trop... Le but de mon système est justement d'éviter cela ! Lors de l'implémentation classique pour ce genre d'évènements, où toutes les possibilités sont déjà prédéfinies, il faut effectivement tout prévoir dès le début ; mais dans mon cas, où je souhaite définir mes évènements dans des DLL, pourquoi serait-ce le cas ?

Je parle (enfin, nous parlons) ici des interfaces : si tu veux faires des maps dont la distribution ne consiste pas à mettre purement et simplement tout le logiciel à jour (ce qui resterait envisageable), il faudra bien que celles-ci communiquent avec ton logiciel principal. Et donc, il faudra que « les tuyaux » soient déjà en place pour cela. Cela peut être un simple accès aux données via un segment de mémoire, mais si tu veux faire des fonctions, il faudra connaître leur prototype à l'avance.

Citation:

Je pensais simplement faire des procédures appelées à la création et à la suppression de la carte, et quelques fonctions qui réagiraient comme des "Listeners" (changement de coordonnées, pression d'un bouton, etc...).

Ce seront en fait des fonctions de call-backs, mais le principe est le même.

Citation:

Je souhaiterais vraiment établir mon système de carte afin qu'il me permette de tout faire sans avoir à retoucher à chaque fois le client lui-même. Dois-je, selon vous, abandonner l'idée de la DLL-carte ?

Non, c'est une bonne idée. Il faut simplement que tu sois clair, dans ton esprit, sur ce qui va relever du simple changement de carte et ce qui va nécessiter une mise à niveau de ton logiciel.

Retiens également que moins tu recours à du code pour faire ce que tu veux faire, mieux ce sera. Fais également en sorte, lorsque tu distribues une nouvelle carte, que les données qui la composent et le code additionnel qu'elles nécessitent se trouvent bien dans des DLL séparées, de façon à pouvoir utiliser ce nouveau code dans d'autres cartes à venir.
12/08/2011, 19h11
Spartx

En fait, je pensais agir grosso-modo ainsi :

- l'aspect graphique est géré via un système de "tuiles" : un "Chipset" se compose d'images de taille égales ("tuiles").
- la DLL contient plusieurs tableaux 2D de coordonnées (si l'élément <a,b> du tableau est <x,y>, la "tuile" <a,b> sur le chipset est affichée en <x*taille d'une tuile, y*taille d'une tuile> sur l'écran) représentant des couches d'éléments graphiques.
- la DLL contient une liste de PNJ.

- à chaque mouvement, les coordonnées sont recalculées via le client et une fonction de la DLL "déplacement(coordonnéeX, coordonnéeY)" est appelée.
- à chaque clic, de la même façon, une fonction de la DLL est appelée ("clic(coordonnéeX, coordonnéeY)").

L'implémentation de ces 2 dernières fonctions changerait donc pour chaque carte.
Le problème est donc : si dans la fonction "déplacement", je veux connaître le pseudonyme du personnage, stocké dans le client, comment dois-je faire ? ou encore, si je veux flouter l'écran, défini aussi dans le client, comment dois-je faire ?

Une solution serait un genre de "dllexport dans les 2 sens", mais est-ce possible ?

J'ai aussi pensé à donner à la DLL une std::map liant des adresses de fonction du client avec des chaînes de caractères, pour pouvoir les appeler de la DLL, mais le problème reste le même : si le type de retour de ces fonctions est défini dans le client, que faire ?
12/08/2011, 23h03
darkrojo

Citation:

Envoyé par Spartx

- la DLL contient plusieurs tableaux 2D de coordonnées (si l'élément <a,b> du tableau est <x,y>, la "tuile" <a,b> sur le chipset est affichée en <x*taille d'une tuile, y*taille d'une tuile> sur l'écran) représentant des couches d'éléments graphiques.
- la DLL contient une liste de PNJ.

AMHA, tu devrais stocker uniquement tes "fonctions" dans ta DLL, car je pense que des tableaux 2D et des PNJ sont facilement serialisables. Tu peux à la rigueur créer une DLL pour chaque PNJ si il a par exemple une fonction d'attaque spécifique.

On ne mélange pas les choux et les oignons (les algorithmes et les données).
12/08/2011, 23h52
Spartx

Il paraît pourtant plus simple de regrouper toutes ces informations ? Ainsi, le passage d'une carte à une autre se traiterait ainsi :
- vérification de la version de la DLL présente
- vérification de son authenticité
- téléchargement de la nouvelle version si besoin est

Cette solution permet de ne vérifier la version et l'authenticité des données et fonctions qu'une seule fois contre deux si on les sépare.

De plus, ces fonctions ne contiendraient pas des algorithmes poussés : quelques "switch" et appels à des fonctions du client.

Enfin, quand je parlais des PNJ, je voulais mentionner les "animations graphiques" ; les données propres à ceux-ci devant rester coté serveur.
13/08/2011, 02h24
oxyde356

En gros tu veux qu'un évènement puisse faire tout et n'importe quoi, donc en gros que ton application permette à un script de faire tout et n'importe donc ... en grOs ... tous les attributs et fonctions en public avec un gestionnaire te permettant d'avoir un accès à tous tes objets et hop ça fera l'affaire ><
13/08/2011, 07h59
3DArchi

Pour les plugins, cf le ¤ dédié dans le tuto de Laurent Gomila:
13/08/2011, 10h04
Spartx

Tout d'abord, merci pour vos réponses !

Le problème avec ce système de plugin ne change pas : je ne peux pas utiliser à l'intérieur des classes de mon client.. :(

Pour le gestionnaire qu'Oxyde356 propose, j'y vois le même problème : mettons qu'à partir de ce gestionnaire, je souhaite obtenir une instance de la classe "Joueur", déclarée dans le client. Comment la traiter dans la DLL ? Je ne pourrais pas avoir accès à ses fonctions ?

Peut être que ma solution résiderait dans une restructuration complète du client : toutes les classes censées être accessible de la DLL-carte et du client serait elle même déclarées dans d'autres DLL. Ce système vous paraît-il efficace ?
13/08/2011, 18h38
Obsidian

Le problème, c'est qu'au bout d'un moment, c'est ton client qui devient « serveur ». Les soucis que tu rencontres sont révélateurs : si tu cherches à « modifier » le code, alors tu cherches à le remplacer.

De là, tu peux suivre plusieurs approches :

— Tu fais un « moteur » qui gère ton jeu, et tu intègres normalement en son sein toutes les nouveautés qui doivent prendre effet dans les nouvelles cartes que tu publies, en soignant les tests de non-régression, et en maintenant une politique propre de numéros de version. De là, à chaque carte, tu associes une version minimum requise du moteur, quitte à le livrer avec la carte. Il n'y a alors qu'une seule mise à jour à faire par nouvelle carte, et seulement si elle est nécessaire. C'est de loin la meilleure solution si tu es seul à développer ou que ton équipe est bien identifiée, car il se passera beaucoup de temps avant que le logiciel soit trop lourd pour être facilement diffusé. En outre, si tu fais du logiciel libre, tu peux t'épargner toute la peine de la partie « push », c'est-à-dire la distribution aux utilisateurs finaux, en déposant ton logiciel-serveur sur les dépôts officiels des systèmes d'exploitation qu'ils utilisent. La mise à jour sera pour ainsi dire transparente ;

— Ou alors, tu fais une boucle principale qui fait circuler des événements, comme dans une interface graphique (X-Window) ou comme la C.API de Windows, et tu publies effectivement tes cartes comme des DLL qui seront toutes chargées par le moteur, chacune d'elles proposant au moins un point d'entrée « init » et une fonction pour être appelée au sein de la boucle. Tu fais en sorte qu'à l'initialisation, tes DLL s'abonnent aux événements qui les intéressent. Ce n'est pas parfait, mais ça permet de couper la poire en deux : d'un côté tu mets dans ton serveur toute une catégorie d'événements et d'informations d'usage général et, de l'autre, tes DLL se font prévenir quand il se passe quelque chose qui est potentiellement dans leur domaine de compétence, et vont chercher elles-mêmes les infos additionnelles dont elles ont besoin.

Citation:

Envoyé par Spartx

Le problème avec ce système de plugin ne change pas : je ne peux pas utiliser à l'intérieur des classes de mon client.. :(

Ben si. Pour injecter du code d'une DLL plugin dans le client :

**** partagé client/plugin :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
class Interface
{
    public:
    void do_it()const
    {
        just_do_it();
    }
 
    private:
    virtual void just_do_it()const=0;
};

**** client :

Code:

1
2
3
4
5
6
7
8
class Client
{
    public:
    void do_something(Interface const &i_)
    {
        i_.do_it();
    }
};

Code:

1
2
3
4
5
6
7
8
9
int main()
{
    CPlugin<Interface> plugin;
    Interface*plug = plugin.Load("Interface");
    Client cl;
    cl.do_something(*plug);
 
    return 0;
}

**** DLL plugin :

Code:

1
2
3
4
5
6
7
8
9
 
class dll_Interface_Implement : public Interface
{
    private:
    virtual void just_do_it()const
    {
        std::cout<<"coucou\n";
    }
};

Code:

1
2
3
4
5
6
 
Interface* StartPlugin()
{
static dll_Interface_Implement instance;
return &instance;
}

Dans l'autre sens, cela marche pareil :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class Interface
{
    public:
    class IDependance
    {
    public:
       void it_yourself()const
       {
          do_it_yourself();
       }
    private:
       virtual void do_it_yourself()const=0;
    };
 
    void do_it(IDependance const& dep_)const
    {
        just_do_it(dep_);
    }
 
    private:
    virtual void just_do_it(IDependance const&dep_)const=0;
};

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
class ClientDependance : public Interface::IDependance
{
private:
   void do_it_yourself()const
   {
      std::cout<<"coucou\n";
   }
};
 
class Client
{
    public:
    void do_something(Interface const &i_)
    {
       ClientDependance dep;
        i_.do_it(dep);
    }
};
 
int main()
{
    CPlugin<Interface> plugin;
    Interface*plug = plugin.Load("Interface");
    Client cl;
    cl.do_something(*plug);
 
    return 0;
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class dll_Interface_Implement : public Interface
{
    private:
    virtual void just_do_it(IDependance const& dep_)const
    {
        dep_.it_yourself();
    }
};
 
Interface* StartPlugin()
{
static dll_Interface_Implement instance;
return &instance;
}

13/08/2011, 20h03
3DArchi

A la relecture, tu devrais regarder les outils de scripting pour laisser plus de possibilités aux plugin, par exemple Boost.Python : export des objets du client vers python, écriture des 'plugin' avec python et exécution dans le client.
Lua est aussi un outil de scripting que l'on voit souvent proposé pour étendre une application.
13/08/2011, 23h31
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)
14/08/2011, 09h18
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.
14/08/2011, 09h48
3DArchi

Salut,

Citation:

Envoyé par Spartx

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 ?

Citation:

Envoyé par Spartx

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.
14/08/2011, 09h59
Spartx

Citation:

Envoyé par 3DArchi

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
14/08/2011, 17h33
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.
18/08/2011, 09h57
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 :)
25/08/2011, 00h42
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.
25/08/2011, 02h03
Emmanuel Deloget

Citation:

Envoyé par 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.

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

Fuseau horaire GMT +2. Il est actuellement 23h58.