Discussion :

[italiasky]

Bonjour,

Voila, j'ai environ 10 DLL qui sont chargées en mémoire avec mon prog.

Les DLL occupent environ 130Mo en mémoire et mon programme n'a pas toujours besoin de toutes ces DLL.

J'aimerais donc charger que celles dont j'ai besoin au moment de l'exécution...

Je me suis renseigné sur LoadLibrary mais j'aurais quelques questions quand même...

Mes DLL étant déjà créées, est-ce qu'elles doivent être recompilé d'une certaine façon pour les utiliser avec LoadLibrary ou celles que j'ai iront très bien ?

J'ai vu avec LoadLibrary, comment utiliser une fonction après mais moi c'est les classes contenues dans les librairies que j'aimerais utiliser... créer un objet d'un type qui est dans la DLL, est-ce possible ? Comment faire ?

Merci
++

[Médinoc]

Tu ne peux pas utiliser dynamiquement une classe C++ si elle n'a pas été prévue pour ça.

Le plus souvent, on passe par des interfaces (classes abstraites dont toutes les fonctions membres sont virtuelles pures) et la DLL exporte une juste fonction qui retourne un pointeur vers une classe dérivée instanciée sur le tas.
Mais par contre, ça nécessite l'allocation dynamique, donc pour une classe RAII, ça ne sert à rien... (mais tu peux toujours utiliser un pointeur intelligent vers une instance de classe).

Pour la destruction, soit la DLL fournit une fonction de destruction, soit la classe et son interface comprennent une fonction virtuelle qui fait un delete this.
C'est ce que font les objets COM, sauf qu'ils incluent un comptage de références intrusif et un mécanisme basique pour un équivalent à dynamic_cast<>.

[italiasky]

hum ui, en clair, c'est pas très simple quoi... lol
parce que je vois pas tout à fait là...

Enfin, ok merci quand même

[Profman]

Pour utiliser des DLLs qui ne sont pas charger au démarrage du processus. Il ne faut pas "linker" le programme client avec la 'lib' (*.lib) généré avec la DLL.

Scénario :

L’ API : LoadLibray permet le chargement de la DLL et retourne un « ticket d’utilisation » et la « loge » dans l’espace d’adressage du processus.

HINSTANCE LoadLibrary( LPCTSTR lpLibFileName );

L’ API : FreeLibrary provoque le déchargement de la DLL de l’espace d’adressage du processus (si possible).

BOOL FreeLibrary( HMODULE hLibModule );[/FONT]

L’ API : GetProcAdress retrouve l’adresse mémoire d’une fonction exportée d’une DLL.

FARPROC GetProcAddress( HMODULE hModule, LPCSTR lpProcName );

Ensuite avec le pointeur de fonction tu peux appeler les méthodes.

Bon courage ^^

[Médinoc]

Ça, c'est bien pour des fonctions indépendantes. C'est quand même beaucoup plus compliqué d'appeler des méthodes de classe avec ça (rien que pour faire le GetProcAddress(), tu en baves).

[Profman]

Ça, c'est bien pour des fonctions indépendantes. C'est quand même beaucoup plus compliqué d'appeler des méthodes de classe avec ça (rien que pour faire le GetProcAddress(), tu en baves).

Vrai c'est pas sexy mais bon ...

[bacelar]

Outre le problème des classes de Dll instanciables, vrais beau de banane qui rend bien précocement chauves les programmeurs imprudents; il existe depuis VS6 le concept de dll delay-loadé.
Cela permet de ne charger les dll qu'au moment de leur première utilisation.
Cela permet d'accélérer le chargement de l'application et d'utiliser des références vers des dll qui n'existent pas forcement sur la plateforme d'exécution comme utilisé une dll qui n'existe que sous WinNT ET une dll qui n'existe que sous Win9X.
Cerise sur le gâteau, les dll delay-loadé s'utilise exactement comme des dll classiques (pas de loadlibrary etc...). Ce n'est qu'une option de l'éditeur de lien à mettre. Oui, c'est une très très grosse cerise.

P.S.: le fait d'utiliser de nombreuses dll n'a qu'un faible impacte sur la mémoire réellement utilisée par le programme. Le working-set moyen de votre programme est un indicateur bien plus pertinent en cas d'utilisation intensive de la mémoire.