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" );

typedef class <= what's that
 
 
Fo que tu reprennes tes cours sur les DLL  

vaut mieux faire
 
class MaClasse {
//
};
typedef MaClasse * pMaClasse;
 
?

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 ?

j'utilise vc++7, dsl de pas l'avoir précisé
 
sinon, pour exporter ma classe il me semble que je doive faire :
 

 
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 :
 

 
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 ?

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

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

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 ?

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

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

j'ai testé la méthode de gatorette :  
 
dans ma dll :
 

 
j'ai exporté les fonctions _new et _delete
 
puis dans mon executable :
 

 
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

joue la comme ca
 
:
 
DLL :
 

 
 
Exe :

 
le reste a peu pres comme tu fais

+ oublie pas le . res de ta dll

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

merci, ca marche impeccable.
 
par contre il va vraiment falloir que je me documente sur les méthodes virtuelles parce que je tatonne ...

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 ?

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

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

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

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

Moi je fais comme ca :
 

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

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

mmh.
 
et si on fait :

 
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 :

 
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.

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

bien, encore merci pour ces précisions

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

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

 
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 :

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

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