Discussion :

[Spartx]

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 !

[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.

[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....

[Obsidian]

Bonjour,

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

[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 !

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 !

[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

[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:ython ...), 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).

[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.

[Spartx]

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 ?

[Obsidian]

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.

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.

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.

[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 ?

[darkrojo]

- 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).

[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.

[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 ><

[3DArchi]

Pour les plugins, cf le ¤ dédié dans le tuto de Laurent Gomila:

[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 ?

[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.

[3DArchi]

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 inteface.h :

Sélectionner tout - Visualiser dans une fenêtre à part

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 client.h :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code main.cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

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 dllPlugin.h :

Sélectionner tout - Visualiser dans une fenêtre à part

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 dllPlugin.cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[3DArchi]

Dans l'autre sens, cela marche pareil :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
}

[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.