Skip to main content
GameDev.net gamedev.net
🔒 Locked

STL string across DLL

Started by Simplicity Apr 17, 2006 at 12:45 AM 2 replies 650+ views
Original Post
Simplicity
Simplicity
Can I use STL across DLLs? Let's say I have DLL1 that declares: class DLL1_EXPORT A { private: std::string m_String; } And DLL2 imports class A and inherits from it: class DLL2_EXPORT B : public A { } Will this cause problem when we start using these classes? What about for other containers like map, list, etc? This link describes several things and it applies to VC++ 5 and 6. What about for .NET? [a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;168958"]Link[/a]
blaze02
blaze02
I'm not exactly sure how you are inheriting across DLLs (I haven't worked with them much). I do know that DLLs declare variables on a per-instance basis. I.E: if prog1 and prog2 use the same DLL, the variables in the DLL are created twice and do not collide.
Evil Steve
Evil Steve
You can only use STL containers (std::strings included) if:
  • You're runing Linux

  • You link to the DLL version of the CRT from both the EXE and DLL.

  • Or you only pass by STL containers by const reference

In Windows, each module (EXE or DLL) gets its own heap. You can't allocate something from one heap and free it in another. STL containers cause issues, because they're constantly allocating and releasing memory. If you pass a std::string to a function in a DLL, and it tries to append data to it, and it has to reallocate memory then it'll have to free the old memory. That usually results in a call to delete[], which - because it's called in the DLL - tries to free the memory from the DLLs heap. The memory was allocated by the EXE, so boom. Access Violation.
This problem doesn't occur in Linux because it doesn't have the same notion of heaps, and there isn't a problem in allocating memory in a DLL (Well, shared object) and freeing it in a EXE.

Using the DLL version of the CRT solves this problem because then both the DLL and EXE link to the same instance of the CRT DLL, and call new and delete from the same heap - the heap in the CRT DLL.
Simplicity
Simplicity
So the DLL problem only presist in Windows? Including the problem of creating and destroying objects across dynamic libraries?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.