C++

(win32) classe dans une dll

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : (win32) classe dans une dll

blackgoddess

vive le troll !

bonjour, j'ai compilé une dll avec une classe dedans, dont j'ai la déclaration :

typedef class MaClasse
{
public:
void Membre();
} MaClasse, *pMaClasse;

comment faire pour l'instancier apres avoir chargé ma dll ?

HMODULE hMod = LoadLibrary("MaDLL" );

---------------
-( BlackGoddess )-

Publicité

chrisbk

typedef class <= what's that

Fo que tu reprennes tes cours sur les DLL

blackgoddess

vive le troll !

vaut mieux faire

class MaClasse {
//
};
typedef MaClasse * pMaClasse;

?

---------------
-( BlackGoddess )-

chrisbk

c juste que je trouve ca moche
dans l'ensemble chui rarement fan des types qui cachent qu'un objet est un ptr... enfin bon c pas le pb

tu peux pas instance directement une classe comme tu compte le faire, ou alors il faut exporter ta classe de ta dll

T'utilise quoi cmme compilo ?

blackgoddess

vive le troll !

j'utilise vc++7, dsl de pas l'avoir précisé

sinon, pour exporter ma classe il me semble que je doive faire :

Code :

class __declspec(dllexport) MaClasse {
//
};

ou, d'apres le générateur de vc++ pour pouvoir utiliser le meme header pour la DLL et pour les executables qui l'appeleront :

Code :

#ifdef MADLL_EXPORTS
#define MADLL_API __declspec(dllexport)
#else
#define MADLL_API __declspec(dllimport)
#endif
class MADLL_API MaClasse {
//
};

ensuite donc je charge ma DLL avec LoadLibrary (c'est impératif)

---------------
-( BlackGoddess )-

chrisbk

Citation :

ensuite donc je charge ma DLL avec LoadLibrary (c'est impératif)

hum
la c'est embetant
tu peux pas utiliser la lib que visual te recrache et la linker a ton exe ?

gatorette

BlackGoddess a écrit :

ensuite donc je charge ma DLL avec LoadLibrary (c'est impératif)

Tu ne pourras donc pas importer directement des classes comme ça. En effet, la seule fontion disponible est alors GetProcAddress qui ne sait charger que des fonctions.
Il faut que tu passes par des techniques un peu différente. COM est celle utilisée en standard dans Windows mais tu peux faire des choses plus simple (une fonction dans ta dll qui fait un new et renvoie un pointeur vers ton objet et une fonction pour le deleter peut suffire).

---------------
each day I don't die is cheating

ACut

gatorette a écrit :

En effet, la seule fontion disponible est alors GetProcAddress qui ne sait charger que des fonctions.
Il faut que tu passes par des techniques un peu différente. COM est celle utilisée en standard dans Windows mais tu peux faire des choses plus simple (une fonction dans ta dll qui fait un new et renvoie un pointeur vers ton objet et une fonction pour le deleter peut suffire).

Excellente info, gatorette, merci. (C'est un pb qui me taraudait moi aussi...)

---------------
NOUVEAU! Le guide de l'édition en version ebook : http://marcautret.free.fr/autret/150q-ebook/

blackgoddess

vive le troll !

tu peux pas utiliser la lib que visual te recrache et la linker a ton exe ?

>> c'est pour créer un système de plugin, je ne peux pas me permettre de relinker mon projet à chaque ajout/suppression de plugin.

excellente idée gatorette merci, sinon aurais-tu des infos sur la technique COM ?

---------------
-( BlackGoddess )-

chrisbk

bon, ben methode 3dsmax que je trouve de tres bon gout : classe de base avec methode virtuelle pure, deux fonction exportee de la dll :

->une donnant le nombre de plug in contenu
->une creant un objet "plugin numero i"

et roule simone

Publicité

blackgoddess

vive le troll !

je maitrise pas encore super bien le ++ du c ... je vais donc deja me documenter sur les méthodes virtuelles pures avant d'essayer de comprendre ...

---------------
-( BlackGoddess )-

blackgoddess

vive le troll !

j'ai testé la méthode de gatorette :

dans ma dll :

Code :

#include <windows.h>
class CTest
{
public:
CTest();
~CTest();
void Membre();
};
CTest::CTest()
{
MessageBox(NULL, "CTor", "CTest", NULL);
}
CTest::~CTest()
{
MessageBox(NULL, "DTor", "CTest", NULL);
}
void CTest::Membre()
{
MessageBox(NULL, "Membre", "CTest", NULL);
}
CTest* WINAPI _new()
{
return new CTest();
}
void WINAPI _delete(CTest* Test)
{
delete Test;
}

j'ai exporté les fonctions _new et _delete

puis dans mon executable :

Code :

#include <windows.h>
class CTest
{
public:
CTest();
~CTest();
void Membre();
};
typedef CTest* (WINAPI* fnew)();
typedef void (WINAPI* fdelete)(CTest* Test);
int WINAPI WinMain(HINSTANCE hi, HINSTANCE hp, LPSTR cl, int ns)
{
HMODULE hMod = LoadLibrary("testdll" );
fnew _new = (fnew)GetProcAddress(hMod, "_new" );
fdelete _delete = (fdelete)GetProcAddress(hMod, "_delete" );
CTest* test = _new();
test->Membre();
_delete(test);
return 0;
}

le problème à la compilation :

error LNK2019: symbole externe non résolu "public: void __thiscall CTest::Membre(void)" (?Membre@CTest@@QAEXXZ) référencé dans la fonction _WinMain@16

---------------
-( BlackGoddess )-

chrisbk

joue la comme ca

:

DLL :

Code :

class CTest
{
public:
virtual void Membre()=0;
};
class CTest2:public CTest
{
public:
virtual void Membre(){}
}
extern "C"
{
CTest* WINAPI _new()
{
return new CTest2();
}
void WINAPI _delete(CTest* Test)
{
delete Test;
}
}

Exe :

Code :

class CTest
{
public:
virtual void Membre()=0;
};

le reste a peu pres comme tu fais

chrisbk

+ oublie pas le . res de ta dll

HelloWorld

Salut tout le monde!

Normal l'erreur, t'as pas défini ta methode.
Tente en spécifiant ta classe comme importée.
Je trouve que ton code commence à ressembler à une classe C++ utilisée à la C.
Pourquoi ne pas exporter une structure et des fonctions C et écrire un wrapper C++ ?

Sinon COM pour un plugin c'est bien oui. Mais c'est pas évident...

---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite

blackgoddess

vive le troll !

merci, ca marche impeccable.

par contre il va vraiment falloir que je me documente sur les méthodes virtuelles parce que je tatonne ...

---------------
-( BlackGoddess )-

VisualC++

J'va y penser ...

Juste pour repondre a Gatorette, on peu si utilisation MFC (et AFXEXT) creer des DLL exportant des Class (pure ou pas).
Par contre jamais teste si Win32 pure.

Edit : BlackGoddess au fait pkoi LoadLibrary imperatif pour toi ?

Message édité par VisualC++ le 26-08-2003 à 19:28:51

blackgoddess

vive le troll !

VisualC++

bien, si je fais mon plugin en dll (la méthode la moins contraignante je pense par rapport a la 2eme méthode : COM car il n'y a pas besoin d'enregistrer son plugin alors qu'avec COM d'apres ce que j'ai compris c'est obligatoire) il y a 2 méthodes pour la charger : l'inclure "en dur" au linkage, ou la charger avec LoadLibrary puis appeler ses fonctions avec GetProcAddress.

la méthode au linkage est à éliminer car je ne sais pas par avance le nom de mes plugins, leur nombre, etc. Reste donc la 2eme méthode.

Si tu vois une autre solution je suis preneur

---------------
-( BlackGoddess )-

gatorette

VisualC++ a écrit :

Juste pour repondre a Gatorette, on peu si utilisation MFC (et AFXEXT) creer des DLL exportant des Class (pure ou pas).
Par contre jamais teste si Win32 pure.

Je ne connais pas ce type de DLL (j'utilise de moins en moins les MFCs maintenant que j'ai découvert la WTL) mais je ne pense pas que tu puisse lier ta bibliothèque de façon dynamique.
Et de façon statique, il est possible (avec Visual C++) d'exporter n'importe quelle classe MFC ou non (exception faite des classes avec templates).

---------------
each day I don't die is cheating

gatorette

BlackGoddess a écrit :

...il n'y a pas besoin d'enregistrer son plugin alors qu'avec COM d'apres ce que j'ai compris c'est obligatoire...

Il est obligatoire d'enregistrer ses interfaces avec COM mais ce n'est pas très contraignant (quelques fonctions à implémenter qui sont créées automatiquement si tu utilises ATL ou que tu peux facilement adapter d'un exemple sinon). Mais l'avantage de COM est que tu n'as pas besoin de connaître le nom ou l'emplacement des DLLs.
COM a aussi l'avantage d'être la technologie utilisée par Microsoft pour avoir des "objets dynamiques". Les technologies récentes de Microsoft l'utilisent partout (Shell, DirectX...) et que beaucoup de gens connaissent et savent utiliser. De plus, c'est un système éprouvé et qui a dû demander pas mal de réflexion.
Il peut être intéressant de te pencher sur DirectShow et ses filtres. Le peu que j'en connaisse, c'est un système très riche. De plus, selon ton application, il peut être intéressant de pouvoir réutiliser les centaines (?), milliers (?) de filtres existants.

J'ai fait l'apologie de COM ici, mais c'est juste pour te montrer que la complexité n'est pas insurmontable et que c'est une technologie qui a certains avantages. Mais j'utilise pour le moment mon propre système que j'ai développé !
Une voie à explorer (si tu as le temps), c'est de regarder comment sont faits les API de logiciels communs utilisant des plug-ins (Winamp, 3DS-Max, Photoshop...).

---------------
each day I don't die is cheating

chrisbk

3ds c'est comme j'ai expliqué : une DLL exportant des classes via une fonction de dll exporté (je suis hyper clair je sais)

Enfin, plus precisement :

la dll comprends deux fonctions :
->nombre de plugs in contenu
->fonction pour avoir une description du plug in n°i

la description donne le type du plug in (modifier, export...) et a aussi un fonction permettant la creation de l'objet plug in en lui meme. Ceux ci derivent tjs de classes de bases issu de 3dsmax (SimpleModifier....)

C'est relativement simple a faire, et assez efficace aussi

Ashe2

Moi je fais comme ca :

Code :

// A partager entre le code client et la dll
class Interface
{
public:
virtual void Release() = 0;
virtual void Methode1() = 0;
virtual void Methode2() = 0;
};
// Dans la DLL
class Implementation : public Interface
{
public:
Implementation() { }
~Implementation() { }
void Release()
{
delete this;
}
void Methode1() { }
void Methode2() { }
};
extern "C" __declspec(dllexport) void CreerInstance( Interface *& blah )
{
blah = new Implementation;
}
// Code client
typedef void (* BLEH)( Interface *& );
HMODULE hLib = LoadLibrary( "gnagna.dll" );
BLEH fonction = reinterpret_cast<BLEH>(GetProcAddress( hLib, "CreerInstance" ));
Interface * objet;
fonction( objet );
object->Methode1();
object->Methode2();
object->Release();

blackgoddess

vive le troll !

c'etait la méthode abordée par chrisbk en plus développée, elle me plait beaucoup

je ne savais pas qu'il était possible de faire : delete this;
ca evite de devoir exporter une 2eme fonction

merci beaucoup

---------------
-( BlackGoddess )-

gatorette

BlackGoddess a écrit :

je ne savais pas qu'il était possible de faire : delete this;
ca evite de devoir exporter une 2eme fonction

Il n'est pas impossible de faire des delete this; mais je trouve que cela devrait être évité à tout prix (et je ne suis pas le seul !).
Voici quelques articles sur le sujet ici ; et surtout celui-ci qui présente pas mal de raisons de ne pas faire delete this.

--edit--
Correction d'un tag

Message édité par gatorette le 28-08-2003 à 01:10:47

---------------
each day I don't die is cheating

blackgoddess

vive le troll !

mmh.

et si on fait :

Code :

// Code client
typedef void (* BLEH)( Interface *& );
HMODULE hLib = LoadLibrary( "gnagna.dll" );
BLEH fonction = reinterpret_cast<BLEH>(GetProcAddress( hLib, "CreerInstance" ));
Interface * objet;
fonction( objet );
object->Methode1();
object->Methode2();
delete object;

je suppose que c'est mauvais car le heap de l'executable et le heap de la dll n'est le meme ?

---------------
-( BlackGoddess )-

gatorette

BlackGoddess a écrit :

je suppose que c'est mauvais car le heap de l'executable et le heap de la dll n'est le meme ?

Je ne sais pas trop sur ce point là, mais c'est de toute façon mauvais car tu n'es pas sûr de la façon dont ton objet a été créé.

Que se passe t'il si le plug-in se comporte comme ça :

Code :

// variable globale
Interface monObj;
// fonction de création
Interface * WINAPI CreerObjet()
{
return( &monObj );
}

Ton application va planter au moment du delete ! Il me semble important de laisser la responsabilité de la création et de la destruction à la même personne.

---------------
each day I don't die is cheating

HelloWorld

Salut tout le monde!

Citation :

je suppose que c'est mauvais car le heap de l'executable et le heap de la dll n'est le meme ?

Oui. C'est même pire que ça, car les lib standards peuvent être différentes ou de version différente (genre un prog BCB qui fait un delete sur un objet d'une dll VC++ ...).

---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite

blackgoddess

vive le troll !

bien, encore merci pour ces précisions

---------------
-( BlackGoddess )-

Ashe2

Il n'y a aucun problème a faire un delete this;, la méthode Release de COM fait la même chose.
De plus dans le logiciel qu'on développe pour le moment on a une 30aine d'interfaces créées de cette façon, ca n'a jamais planté, et c'est compilé avec 7 compilateurs différents sur 4 OS et 3 consoles...

blackgoddess

vive le troll !

lool je prends note de la fiabilité évidente de cette méthode

---------------
-( BlackGoddess )-

Ashe2

gatorette a écrit :

Que se passe t'il si le plug-in se comporte comme ça :

Code :

// variable globale
Interface monObj;
// fonction de création
Interface * WINAPI CreerObjet()
{
return( &monObj );
}

Ton application va planter au moment du delete ! Il me semble important de laisser la responsabilité de la création et de la destruction à la même personne.

Une interface (ou une classe abstraite, pour parler en C++) ne peut pas être instanciée...

gatorette

Ashe2 a écrit :

Une interface (ou une classe abstraite, pour parler en C++) ne peut pas être instanciée...

J'ai appelé abusivement ma classe Interface. Ce qui rend mon code peu compréhensible.

Code dans la DLL :

Code :

class Interface
{
//
// des fonctions purement virtuelles
//
};
class MonPlugin : public Interface
{
//
// implémentation des fonctions d'Interface
//
}
// variable globale
MonPlugin monObj;
// fonction de création
Interface * WINAPI CreerObjet()
{
return( &monObj );
}

J'espère que c'est plus clair.

---------------
each day I don't die is cheating

Ashe2

Désolé, tt facon j'avais pas vu que tu parlais du code du plugin

Publicité

FORUM HardWare.fr

Programmation

C++

(win32) classe dans une dll

Sujets relatifs
[Win32] Editeur de ressources .rc ?	[python]classe + liste dans constructeur ??
[C Win32] Utilisation de la fonction CreateDialog()	Win32 console application plus rapide qu'une application Windows
Membres d'une classe singleton	Référence à une fonction d'une autre classe
[C++] threads Win32	Classe de lecture de fichier encodées - Approche Objet
[C++ Builder] Win32 Error. Code : 1410.La classe existe déjà	[Win32 VisualC++] classe Win32 "SysDateTimePick32"
Plus de sujets relatifs à : (win32) classe dans une dll

Page générée en 0.122 secondes