Discussion :

[tut]

salut,
je récupère des std::string, allouée dans une DLL, en utilisant l'opérateur = :

StringExe = StringDll;

Quand je passe dans le destructeur de la classe qui contient les chaînes de l'exe, j'ai un plantage (en mode Debug) sur CrtIsValidHeapPointer(); qui indique que le destructeur tente de libérer de la mémoire allouée dans la DLL.

Question : l'operateur = de std::string, fait une vraie recopie physique ? nouvelle espace mémoire, etc ?

[Aurelien.Regat-Barrel]

Mauvaise nouvelle : il ne faut pas utiliser la STL dans les exports d'une dll... Ta dll est compilée avec un autre compilo je présume, un compilo qui a sa propre STL qui opère différement parrapport à ta STL, le linker n'y voie que du feux, et boum.

[Laurent Gomila]

Même avec le même compilo, ça risque de planter. Chaque DLL a sa propre zone d'allocation (tas), donc si tu détruis avec une DLL une variable allouée dans l'autre, boom aussi...

Une solution est en général d'utiliser la version dynamique de la bibliothèque standard, ainsi plus de problème.

Question : l'operateur = de std::string, fait une vraie recopie physique ? nouvelle espace mémoire, etc ?

Ca dépend de la stratégie implémentée dans ta STL : si elle utilise le Copy-On-Write, probable que non.

[Aurelien.Regat-Barrel]

Une solution est en général d'utiliser la version dynamique de la bibliothèque standard, ainsi plus de problème.

Pour la STL dynamique / statique ça change pas grand chose. Même si c'est la même lib standard, si 2 implémentations de std::string se confrontent (COW vs normal par ex) boom (faudrait tester tiens, un prog VC++ 7.1 par exemple avec une dll qui utilise STLPORT sur le même compilo).
Même appeler c_str() je ne suis pas sûr que ça marche à 100%. Je pense même que ça change pas grand chose.
On peut exporter certaines parties de la STL. J'étais resté sur l'idée d'une 3° dll à part qui ne compile et exporte que la STL, les 2 autres l'utilisent. Mais beaucoup de bidouille pour une solution dont je ne sais pas si ça marcherait avec autre chose que VC++, j'ai laissé tomber.

[Laurent Gomila]

On peut exporter certaines parties de la STL. J'étais resté sur l'idée d'une 3° dll à part qui ne compile et exporte que la STL

C'est ça que je voulais dire en parlant de lier avec la bibliothèque standard dynamique. Ca va produire exactement ce que tu dis, à savoir une troisième DLL qui n'exporte que la STL.

Sinon oui, si on utilise pas la même version de la STL dans les 2 modules, boom dans tous les cas.

[tut]

j'utilise Visual C++ 6.0, dans le même Workspace j'ai plusieurs projets, dont la fameuse DLL. Donc, même compilo, même version de STL.
Je vais essayer de bricoler avec un buffer de char local.

[Laurent Gomila]

Je vais essayer de bricoler avec un buffer de char local

Si tu lies avec la RTL tu n'auras aucun souci .

[tut]

la RTL ? rien à voir avec Fabrice et Jean Roucas, je présume,
tu veux pas éclairer ma lanterne à la lueur de ton expérience ?

[Aurelien.Regat-Barrel]

RunTime Librairy : bibliothèque dynamique => version dll de la lib standard (msvcrt.dll...).

[Laurent Gomila]

la RTL ? rien à voir avec Fabrice et Jean Roucas, je présume

Non en effet . En liant avec la bibliothèque standard dynamique, tu vas utiliser la DLL prévue à cet effet (MSCVCRT.DLL avec VC++) plutot que le .lib qui serait inclu à ton binaire après compilation. Ainsi tout ce qui sera allocation / désallocation sur des éléments de la bibliothèque standard seront bien tous effectués dans la même DLL.

Dans les options de VC6, c'est "Setting" -> "C/C++"' -> "Code generation" -> "Use run-time library" -> "(Debug) Multithreaded DLL".

[tut]

Merci Messieurs.