   Modifying STL objects from a DLL
  I've been doing a lot of searching in these forums on the topic of accessing STL objects across DLL borders, and everything I've read so far seems to indicate that this is a bad idea and very difficult and platform-specific to pull off (yes, I'm aware that DLLs themselves are platform-specific, but the rest of my engine is not, so I need the interfaces to act consistent).Where exactly is the problem in combining DLLs and STL objects? Take two examples: First example, lets say my application calls a function located within a loaded DLL, and as a parameter to that function it passes a pointer or reference to a std::string (or other STL object), for the DLL function to fill. Pretty simple. Second example, the application calls a function located within a loaded DLL, passing no parameters, but getting a std::string (or other STL object) as a return value that the DLL created.From what I've read, the second one is guaranteed to have problems, but what about the first one?The only consistent alternative I can think of is to resort back to the old days of char arrays. But after all I've learned about the evils of char arrays and using std::strings for everything, the idea of going back and trying to preallocate arrays and do it all manually is very unappealing.Is this really my only option? Is there any method of allowing DLLs to modify application STL objects without issues and without weird hacks?   
  In theory, there should be no problem.  In practice, there could be.For example, Microsoft Visual C++ 6.0 shipped with an STL implementation from Dinkumware.  That implementation had a nasty problem.  The xtree template class stored its NIL object as a static data member.  When a DLL library instantiated an xtree object, you got a static NIL object in that module.  When the EXE library used the xtree template, you got *another* static NIL object.  Iteration over elements in a container class in the EXE module wound up comparing to the NIL of the DLL, which is incorrect.  (I spent a long time tracking down this bug, thinking it was something wrong with my code.);  Won't switching to DLL-specific version of the run-time library help alleviate this problem?   ;  From what I read, using the DLL version of the runtime just makes sure that the application and DLL share the same local heap. Which I can understand if the DLL creates a local object and tries to pass that to the application. But what if the application creates an object ahead of time and just passes a reference to it to the DLL, and the DLL just modifies that? I would assume it would be fine, but then because some STL objects involve additional memory allocation (string or vector size increases), I didn't know if it would try to reallocate itself using DLL memory... Very confusing.Is the only real guaranteed method to just stick with non-STL objects when passing data between the application and the DLL? Are char arrays still necessary?   ;  You can use STL objects across DLL boundaries if you can ensure the following,exe and DLL were compiled with the same STL implementationexe and DLL share same CRTwhich also means exe and DLL were compiled with same compilerThe problem arises for a few reasons. The CRT problem has already been attributed to not sharing the same heap. By ensuring both link to the same runtime, it should not be a problem.The STL specific problem stems from different implementations and STL's template/header nature. For example, the internal layout of an STL class could differ between implementations in size and variables. Eg A's implementation of string could store the data in byte 0. When u pass this string to another module compiled with STL B, the data could be stored in byte 20 of the string obj, and it starts looking from byte 20, possibly reading past the objects memory.Even minor differences in compiler options can cause your applications to crash at the most unexpected times. I was compiling my DLL/external libraries and exe in VS2005, yet used to get random crashes. The problem went away if i stopped declaring SECURE_SCL 0. I later discovered that my boost library was not compiling with the SECURE_SCL 0 because bjam was ignoring it. I manually added the define to the boost header and now all the problems have vanished.   ;  You should also export used instances of STL classes from a DLL. Otherwise STL classes that use any shared state, such as pooled allocators, can become desynchronized between the executable and the DLL.   ;  So basically any STL class that gets passed between the application and DLL, regardless of which side created it, should be exported by the DLL? I'll see if I can find the post that described how to do that.I assume there is something similar on the Linux side to make this work as well? Ultimately I need to be able to pass these STL objects back and forth through an interface, regardless of platform, and know it will work regardless.If all I have to do is guarantee that the application and the DLL are compiled in the same way (same libraries, same options, etc.) and do a few DLL exports, without actually hacking up the code itself, then I should be good to go.;Quote:Original post by NairouUltimately I need to be able to pass these STL objects back and forth through an interface, regardless of platform, and know it will work regardless.If all of the code that deals with the STL containers is in the DLL, it'll be fine. It's only when you expose functions in your EXE interface that give or take STL objects that there's a problem.Do you really need that? Can't you do without STL objects on the boundary?   ;  Yeah I'd like to avoid the whole issue and not pass STL objects, it just gets messy.For example, I have the application calling a DLL function which returns a vector of strings (std::vector<std::string>), to give the names of a set of devices. The application doesn't know how many device names it will return, so it can't easily pre-allocate an array. And the only alternative to strings would be to pre-allocate some char arrays. Its doable, but it means setting length limits and coming up with a system to parse out several char array strings from the data returned by the DLL.Using STL objects is, from that standpoint, obviously much simpler and cleaner, but then I have the STL/DLL issue. Its a matter of determining the lesser of the two evils.;  Write a string class which wraps the std string class. Replicate the interface of std::string in your class and export your class from the dll. Then you can safely call the methods of your class, and all of the interactions with the wrapped object will stay in the dll.I've also run into that nil static member issue that was mentioned earlier, and it was a pain to track down. This was on a 64 bit version of the library in vs 2003. We ended up working around it by exporting an interface object at a higher level and only passing that interface object across the boundary, thus keeping all call to the tree in a single DLL.   