Passing standard library classes across DLL boundaries is evil.

The reason for this is that you may well have another DLL, or EXE, or whatever, which uses a different version of the standard library. This can happen even with the "same" compiler - different service packs for Visual Studio, for instance, introduce changes to the standard library implementation.

Suppose I pass a Version X std::map into a DLL. It's defined to accept a std::map, so all compiles cleanly and all appears to be well.

Then I update my compiler, or give my code to someone else, or whatever. The DLL gets compiled again, this time expecting std::map Version Y. I run my program, and Version Y tries to do something new that Version X didn't support. In the absolute best case my program will crash. Far more likely, and far more deadly, is the possibility that the program will continue to run but silently do things incorrectly - leak memory, corrupt data, summon cat-demons from the underworld using a portal generated by the rotations of the hard drive... you name it. The behaviour at this point is what is technically referred to as "undefined" - which is a euphemism for "ohhhh shit."


As the documentation says, don't do this. Expose minimal interfaces between your DLLs which rely only on guaranteed things like integers, char*s, and so on. Then re-wrap those back into standard library classes internally, where appropriate.

The same caveat applies to anything exported across DLL boundaries; I used std::map as an example.

For instance, you can't pass a std::string across boundaries safely. Instead, pass a const char* and use the std::string::c_str() function at the call site, then re-wrap to a string internally in the DLL.

Function objects are analogous. You can't pass a tr1::function across boundaries safely. In this case, the corresponding way to be safe is to use a raw function pointer.

If you need state attached to the function call (i.e. you're using a genuine functor instead of a free function as the callback/hook function) then pass a raw pointer to the state as a parameter of the function. Win32 APIs typically do this with something like an LPVOID, for instance; however, don't use void* if you can help it. Pass a HookState* struct or something.

At this point I've lost track of what changes you've made to the code and what the actual error even is; in the absence of this information, there's really nothing we can do but speculate wildly.

If you can post the current code you have (preferably a minimal example that shows the error) along with the actual, exact copy of all the error messages you're getting, then we'll see what we can do :-)