Discussion :

[mnaulet]

Bonjour,
J'ai cherché des renseignements à propos des librairies sur le net mais quelques points restent encore vague. Le fonctionnement est sous windows.

1. Quelles différences y-a-t'il entre librairie statique et Dll. Librairie statique ne fournit q'un .LIB.

2. Si j'ai un programme qui accède à une Dll A. dans la fonction de la Dll A, j'appelle une fonction de la Dll B qui met à jour une variable globale pour la Dll B.
Une fois terminé ce traitement, je retourne à mon programme principal. J'appelle une autre fonction de la Dll A qui appelle à nouveau une fonction de la Dll B qui accède à la variable globale.
La première valeur de la variable globale est elle gardée? Je ne charge pas la Dll avec un loadLibrary.
Ma variable globale est une structure contenant plusieurs champs dont l'adresse d'une fonction. Lors du premier appel à la DllA, j'appelle une fonction de la DllB en lui passant une adresse qui correspond à une fonction de la Dll A(fonction non exportée). Lors du second appel, je veux appeler depuis la DllB la fonction de la DllA.
Tout fonctionne correctement jusqu'à ce que je fasse appel à cette fonction. J'ai une erreur de windows "privileged instruction". J'ai l'impression en débuggant que l'adresse de la structure est conservée mais pas ses champs.
Ce fonctionnement marche lorsque DllA est un programme directement. Ce problème peut il êtru dû au fait que la fonction que je veux appeler soit dans une Dll et ne soit pas exportée ou peut on quand même appeler la fonction si on connait son adresse?

Merci.

[Médinoc]

1. Bibliothèque statique : Les fonction du .lib nécessaire au programme sont directement recopiées dans le .exe. Si tu as une fonction volumineuse utilisée dans 1000 programmes, tu auras 1000 exe avec cette fonction dedans.
   Et si tu mets à jour ta bibliothèque, tu devras forcément relinker tous les exes.
   
   Bibliothèque dynamique : Le .DLL contient toutes les fonctions, le .lib généré sert à linker le programme à la DLL sans faire de LoadLibrary().
   Dans l'exemple précédent, tu auras 1000 exe sans la fonction et 1 DLL qui la contient.
   Et si tu mets à jour la bibilothèque, avec un peu de chance tu n'auras pas à relinker les exes (je pense que si toute l'interface de la DLL est extern "C", tu n'en as jamais besoin. Des DLLs comme les DLL d'extension MFC, qui sont en C++, font souvent planter si on ne recompile pas le programme qui les utilise).
   .
2. Une DLL chargée dès le début du programme reste généralement chargée pour toute la durée du process, donc ta variable globale devrait être bonne.
   
   Et comme tout est dans le même process, normalement les échanges de pointeurs, surtout des pointeurs de fonction, peuvent se faire sans problème.
   Par contre, ce qui est alloué (malloc, new) par une fonction d'un exe/dll doit être désalloué par une fonction du même exe/dll.
   Il faut aussi faire attention avec les flux (FILE* ou iostream) si les DLLs sont liées avec la version statique de la C RunTime Library.

[Ti-R]

please ?

[_michaël_]

Coucou,

non en fait je crois que les variables globales, tout comme les variables statiques, ne sont pas du tout synchronisés entre le programme appelant et la Dll appelée.
Par exemple, si tu travailles sur deux projets, qui utilisent une libraire commune, contenant un singleton défini comme variable globale ou statique, cette variable sera toujours à sa valeur initiale dans la Dll si tu as crée le singleton dans le programme appelant :
librairie Core contient singleton pCore A et,
librairie Soft B lié à A en mode Exe
librairie Middleware C lié à A en mode Dll
=> B crée A, puis appelle C, le singleton pCore de C sera nul alors qu'il a été crée dans B.

Sinon l'un des avantages interessants des Dlls, c'est de travailler en créant un programme principal qui utilise des petits modules sans réellement savoir ce qu'ils font. Et du coup tu peux donner une version finale d'un programme qui va potentiellement charger de nouvelles fonctionnalités dans des Dlls (c'est l'idée des Plug ins)

à plus

[mnaulet]

OK, merci pour vos réponses qui m'ont éclairées.
Pour le résolu, je ne travaille pas encore le week-end d'où ce petit temps depuis la réponse