Version imprimable
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 ?
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.
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.
Ca d�pend de la strat�gie impl�ment�e dans ta STL : si elle utilise le Copy-On-Write, probable que non.Citation:
Question : l'operateur = de std::string, fait une vraie recopie physique ? nouvelle espace m�moire, etc ?
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).Citation:
Envoy� par Loulou24
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.
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.Citation:
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
Sinon oui, si on utilise pas la m�me version de la STL dans les 2 modules, boom dans tous les cas.
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.
Si tu lies avec la RTL tu n'auras aucun souci :wink:.Citation:
Je vais essayer de bricoler avec un buffer de char local
la RTL ? rien � voir avec Fabrice et Jean Roucas, je pr�sume,
tu veux pas �clairer ma lanterne � la lueur de ton exp�rience ?
RunTime Librairy : biblioth�que dynamique => version dll de la lib standard (msvcrt.dll...).
Non en effet :lol:. 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.Citation:
la RTL ? rien � voir avec Fabrice et Jean Roucas, je pr�sume
Dans les options de VC6, c'est "Setting" -> "C/C++"' -> "Code generation" -> "Use run-time library" -> "(Debug) Multithreaded DLL".
Merci Messieurs.