Discussion :

[scelines]

Bonjour,

Je suis en train de faire une dll en C++ et j'aimerai l'utiliser sous VB (jusque là pas de problème).

Dans cette optique est-il possible de définir des variables globales dans une dll afin de garder en mémoire des données et éviter ainsi de les recharger à chaque appel de la fonction?

Par exemple si j'ai une fonction qui utilise un vector<int> à chaque appel et que ce dernier ne peut pas être défini en dur dans le code, est-il possible de se débrouiller pour le charger au début puis de le réutiliser après dans la fonction de ma dll.

J'espère que ce n'est pas trop flou ce que je raconte

[Aurelien.Regat-Barrel]

Oui. Ta variable persistera tant que ta dll restera chargée et utilisée par le programme.

[Charlemagne]

Oui mais gare au multithread qui ne fait jamais bon ménage avec les variables globales. Une DLL est sensée pouvoir être appelée en parallèle par plusieurs programmes.

J'utilise en général plutôt des variables statiques à l'intérieur de fonctions, mais le problème du multithread reste entier.

Si quelqu'un connait une solution (simple si possible), je suis preneur...
J'imagine qu'il faut s'y prendre avec des mutex, mais j'ai encore jamais touché à ça. Et il parait que la syntaxe sous Windaube n'est pas la même que sous Unix...

[Aurelien.Regat-Barrel]

A moins que ce ne soit la syntaxe UNIX qui soit différente de celle sous Windows.
Tu peux stocker tes variables globales dans un TLS.
http://msdn.microsoft.com/library/en-us/dllproc/base/thread_local_storage.asp
http://www.codeproject.com/threads/tls.asp

[Charlemagne]

Merci, c'est intéressant.

J'imagine qu'il n'est pas possible en pratique de faire plus simple, même si c'est pas une solution miracle. Sur le principe, ça reste simple.
Une déclaration "magique" du genre aurait été bien pratique:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
  multithread_global int i;

J'aime pas l'API de Microsoft car c'est du C avec tout plein de casts, pointeurs, allocations, desallocations: pas pratique et pas très sûr.

Je préfère le deuxième lien. Je n'ai pas regardé le code, mais j'imagine que ça encapsule l'API de Windows.
Il faudrait faire une implémentation différente de cette encapsulation sous différents systèmes, car l'API est très probablement différente d'un système à l'autre. Mais grâce à l'encapsulation, le programme resterait le même.

[Aurelien.Regat-Barrel]

Merci, c'est intéressant.

J'imagine qu'il n'est pas possible en pratique de faire plus simple, même si c'est pas une solution miracle. Sur le principe, ça reste simple.

Il est possible d'utiliser une section tls dans ton exe. Windows & le compilo s'occupent presque de tout.

Une déclaration "magique" du genre aurait été bien pratique:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
  multithread_global int i;

regarde du côté de __declspec(thread).

[Charlemagne]

Il est possible d'utiliser une section tls dans ton exe. Windows & le compilo s'occupent presque de tout.

Je comprends pas ce que tu entends par "section TLS dans le exe".
Et puis quel est le rapport direct avec le compilo? Je considère le TLS comme une library de plus à linker.

regarde du côté de __declspec(thread).

Je connaissais pas.
Une idée intéressante qui aurait pu tout résoudre mais j'ai trouvé ce paragraphe dans la MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Rules_and_Limitations_for_TLS.asp

If a DLL declares any nonlocal data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the nonlocal __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all of the DLLs that are statically linked. When you use LoadLibrary, there is no way to extend this space to allow for the thread local variables declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary.

Je sais pas si le problème est identique sous Unix/Linux

[Aurelien.Regat-Barrel]

Je comprends pas ce que tu entends par "section TLS dans le exe".
Et puis quel est le rapport direct avec le compilo? Je considère le TLS comme une library de plus à linker.

Un fichier PE( exe/dll/...) est composé de diverses section (code, données initialisées, etc...). Il est possible d'avoir une section tls = les données qui y sont contenues le sont en tant que TLS, comme si tu passais par les API, sauf que c'est déjà tout fait par l'OS et rendu transparent par le compilo qui accède à ces variables de manières spécifique, mais transparente => __declspec(thread) sert à déclarer ces variables.

Une idée intéressante qui aurait pu tout résoudre mais j'ai trouvé ce paragraphe dans la MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Rules_and_Limitations_for_TLS.asp

le code sur codeguru gère ce cas (macro TLS_ALLOC).

Je sais pas si le problème est identique sous Unix/Linux

Linux ne supporte pas les TLS depuis bien longtemps il me semble. Je sais pas si le format ELF a été modifié dans ce sens.
Apparement y'a eu une proposition en 2003:
http://people.redhat.com/drepper/tls.pdf
y'a un passage sur le Dynamic Loading. Je sais pas où ils en sont, ce qu'ils fait ni même s'ils l'ont fait.