Salut a tous
 
J'aimerais appeler une fonction dans mon exe qui renvoie une structure.
Est ce que je suis oblige de redefinir la structure dans les sources de l'exe ou alors je peux exporter une structure comme une fonction dans les sources de la dll ??
 
Merci

Tu dois redefinir la structure dans l'exe.
 
En fait le plus simple c'est de le definir dans un .h (ou .pas mais c du c++ toi je pense non?) et de l'inclure dans les deux morceaux...

(gb : tu bosses le week end toi ? )

buitoni -> ok, c'est bien du C++
chrisbk -> ben faut bien sinon le billard il est pas pres d'etre fini
deathsharp ->

Bon pour les struct pas de pb, mais ca veut dire que pour les classes c'est pareil alors ??
 
Parce que j'ai fait une classe CLoad3DS, qui me permet de charger un fichier 3DS. Je veux en faire une dll, que je pourrai donc utiliser dans chaque prochain programme. Mais si je peux pas exporter la classe je fais comment ??

Que ce soit un '.lib', un '.dll', que ça renferme des fonction ou des classes, tu fais systématiquement un '.h'. C'est l'interface publique de tes fonctions (ou classes).  
Si tu écris une collection 'pignouf.dll', tu écris également donc 'pignouf.h', avec les prototypes, les types de données, structures etc.., et plein de commentaires.
Tu mets alors dans le source de l'exe utilisateur:
#include "pignouf.h".
 
Penses à mettre au début de "pignouf.h"(c'est plus propre):
#if !defined(PIGNOUF_H)
#define PIGNOUF_H
.
.
.
.
et à la fin  
#endif
 
Même si ta lib ne te sert qu'à toi tout seul, tu dois pouvoir la réutiliser 6 mois plus tard en lisant simplement le "pignouf.h".

Ouais mais je vois pas a quoi ca sert d'inclure le fichier .h de la dll dans mon .exe, puisque je n'appelle pas directement la classe dans l'exe, je l'appelle a travers la dll.

pkoi tu pourrais pas exporter la classe ?

houla je ne te suis pu
 
mettons, tu as :
 
CLoad3DS
{
void load(char *file);
}
 
 
L'implantation de cette classe se trouve dans ta DLL et dans ton exe tu aurais, genre :
 
CLoad3DS load;
load.load("pouet.3ds" );
 
et donc pour faire cela tu as besoin du .h

Ben pour recupere les fonctions de la dll je fais un LoadLibrary et un GetProcAddress.
Ma dll contient donc un .DEF, dans lequel de toute facon je n'arrive pas a exporter la classe.
 
Mais j'ai pas essaye de faire comme tu me le dis, peut etre que ca fonctionne, mais alors ca me parait tres bizarre, puisque je n'ai meme pas l'adresse de la fonction de la dll...

Je suis pas sûr de piger ton problème, mais je persiste sur l'utilisation des fichiers ".h". C'est comme ça que tu peux appeler des fonction de Windows (qui sont en .dll). Par exemple, si tu utilises une fontion qui renvoie un RECT:
 
#include <windows.h>
#include <windowsx.h>
#include <commctrl.h>
#include <string.h>
RECT Area;
SystemParametersInfo(SPI_GETWORKAREA, 0, &Area,0);  
 
RECT est défini dans windef.h (appelé par un des autres) comme:
typedef struct _RECT {    // rc  
    LONG left;  
    LONG top;  
    LONG right;  
    LONG bottom;  
} RECT;  
 pour tes fonctions à toi, c'est pareil

ok
ben j'essaierai, parce que jusqu'a maintenant je faisais juste un GetProcAdress(hInstLib, "nomfonction" );
 
Mais je vois ca ce soir alors..
 
merci

utilise les DLL avec des export de symbole (cf code genere par visu) pour faire tes classes exportees

 
C'est pas une mauvaise idee, mais je crois qu'il exporte pour un link avec un lib et non un .DEF

 
voui il fait ca avec un chtit .lib (ca t'evite de faire les getProcAdress et tout ca)

 
Nan ca evite pas de faire un getProcAddress, c'est pas du tout pareil.
Dans le cas d'un GetProcAddress, tu fais comme un plug in. Quand tu rebuild ta dll t'as pas besoin de toucher a l'exe.
C'est pas mon cas, donc pas de lib.

comprends pas trop ce que tu veux...

Bon recapitulatif:
 
Projet de Billard en vue.
 
Ce projet va etre compose d'au minimum un exe, et d'une dll dont la fonction sera de charger un fichier 3DS, et de renvoyer le contenu a l'exe dans une structure.
Pourquoi dans une dll ?? Parce que comme ca, pour des projets futurs, j'aurai juste a inclure la dll.
 
Jusque la c'est bon ?
 
La dll:
 
Elle est faite d'une classe.
La seul fonction public de cette classe est CLoad3DS::Import3DS, elle fait tout le travail. Elle demande en argument un nom de fichier, et remplit une structure. (Import3DS(t3DModel *pModel, const char *)).
 
J'ai essaye d'exporter Import3DS, ca marche mais le constructeur n'est pas appele (puisque prog degueu), donc ca marche pas (pointeur non alloue). Je pourrais surement bidouille un peu mais la prog degueu j'aime pas (tu dois le savoir maintenant ).
Je veux donc pouvoir exporter la classe, comme on exporte une fonction.  
 
C'est plus clair la ?
 
Peut etre que la technique de Pierre marche, je ne pourrais essayer que ce soir.

Godbout > pour que le constructeur soit appelle, il faudrait qu'il soit public...
 
pourquoi mettre cette classe dans une Dll ? une fois faite c'est un module, pour le reutiliser il suffit de l'inclure dans le projet et de recompiler...
 
enfin je ne comprends pas trop ta demarche...
tu nous dis vouloir faire ta Dll tel un plug-in, et en meme temps tu voudrais recuperer dans l'exe le resultat

(oue au passage, ca me fait un peu peur ton hstoire parce que a priori si c ta DLL qui charge, c elle qui alloue la memoire . Ce sera donc a elle de la desaouller sinon plantage, fais gaffe a ca)

chrisbk -> C'est la classe qui desalloue tout. Y a pas de pb la dessus.
 
BENB -> Le but de la dll c'etait de pas s'embeter a inclure les .h, etc...
Juste faire appelle a une fonction de la dll, recuperer le resultat, puis pourquoi pas faire une dll pour afficher.

arf, dans tous les cas tu seras quand meme oblige d'inclure un .h
(si tu veux un truc un peu propre)
 
ne serait ce que pour definir le type pointeur sur fonction que tu recup de ta DLL, truc du genre :
 
typedef void (*LPGETRENDERERINFO)(char *desc,int size);
 
au moins a chaque fois que tu utilise ton loader tu n'a pas besoin de le redefinir et si tu le modifie tous seront mis a jour a la prochaine compilation...

dans une Dll ou pas il te faudra inclure tes .h
 
l'interet d'un Dll de mon point de vue, est mineur. Le veritable interet est de pouvoir faire des Plug-In. le reste est beaucoup plus discutable...
 
imagine une classe Plug-in
class PlugIn
{
public:
   enum State
   {
      Undefined,
      Loaded,
      Activated,
   }
   PlugIn();
   PlugIn(const &PlugIn);
   virtual PlugIn& Clone();
   virtual void OnLoad()=0;
   virtual void OnUnLoad()=0;
   virtual void Activate()=0;
   virtual void Run()=0;
   virtual void Stop()=0;
   virtual State GetState()=0;
   virtual ~PlugIn();
};
dont l'implementation peut etre definie dans Une Dll Plug-In
toute modification de cette interface doit etre faite sous la forme d'une nouvelle classe heritant de plug-In (directement ou pas) dans une autre Dll.
 
Quand tu veux faire ta Dll tu surchage les methodes et place cette classe dans une Dll avec une methode Plug-In& GetPlugIn()
qui renvoie une instance de ta classe...
l'exe ne depends que de Plug-In, ta classe depends de Plug-In et pas de l'exe... donc plus besoin de .h... hormis celui de Plug-In

 
 
boah non, mon fatras qui gere les bitmap est dans une DLL...ce WE je l'ai updater (couille dans le chargement des BMP, foutu alignement ) ben la je sais que tous mes progs sont maj....

Certes mais une bonne gestion de tes binires te l'assure aussi...
De plus si tu changes l'interface de ta Dll plus aucun de marche, mais tu ne le sais plus...

j'arrive en cours mais on peux tres bien exporter une classe d'une dll
pour le debut j'avais rien compris

deathsharp a écrit a écrit : j'arrive en cours mais on peux tres bien exporter une classe d'une dll pour le debut j'avais rien compris

 
j'ecoute toutes les propositions alors si tu veux bien donner la tienne...

 
je c pas si g tout compris... mais on peux faire ca sous vc++
en esperant t'aider

[edtdd]--Message édité par deathsharp--[/edtdd]

Ben en fait j'ai pas essaye ca parce qu'il me semble que c'est pour quand tu charges ta dll grace a un lib.
mais merci
je verrai ca

oui il faut la dll et son lib que t'inclu
ca va pas?

nan parce que j'utilise pas les lib

 
mais pkoi

Godbout > de toute maniere il te faudra des dependances dans un sens ou dans l'autre...
 
sol1 -> la lib est independante de l'exe...
tu utilise les .h et le .lib de la dll...
 
sol2 -> l'exe est independant de la dll
c'est la lib qui utilise les .h et le .lib de l'exe, la lib est chargee par LoadLibrary...
 
sol3 > exe et dll sont independants mais dependent d'une meme Dll (stategie Plug-in proposee plus tot dans ce topic)
 
sinon, impossible de partager structures et classes...
 
De plus les dependances que tu crois gommer ainsi sont en fait pires... car en fait tu va utiliser GetProcAdress, et si tu changes le proto de ta Func aie aie aie...

 
ca c la couille, si je rajoute des fonctions dans l'interface bitmap et que je recompile pas tous les projet c plantage direct.....

imagine que tu as une DLL avec 2564 fonctions. tu fait des GetProcAddress pour chacune?
 
avec les lib, je crois qu'il certaine fois ou t pas obliger de toucher a l'exe

C'est pourquoi je suis loin d'etre convaincue par le concept de la Dll, hormis pour les plug-In...

 
Vi c le petit soucis, mais dans l'ensemble je te dirais qu'en tout g eu que tres peu deplantage a cause de ca (maintenant quand il me cause d'ESP en late ou dans le gout je sais ce que ca veut dire )
 
Accesoirement c assez rare que je rajoute des fonctions a la chose, generalement quand je l'utilise dans d'autre projet c deja que c une version stable & utilisable
 
Bon, OK, je bosse pas sur de tres gros projet, ca change un peu tout