The reason STL objects are passed around is because they're part of my ScriptVar type, which is a wrapper around a Lua (Or Python or whatever if I ever decide to support it) variable. Basically, a "any type" variable. And it has functions like:
std::string ToString() const;
Which can't really return a const reference, because that'd mean keeping hold of the buffer in the script var, and all sorts of mess. Basically it just won't work.
So, I got my hands dirty and changed it all to use const char* and a flat array instead of a vector for array ScriptVar types.
Then I realised that my memory manager (Which overrides new and delete in debug builds) was asserting because the block header was invalid. That's because the EXE was compiling as debug, and was using my memory manager for new and delete, but the DLL wasn't, and was using the normal new and delete. Deleting the memory from in the EXE causes it to check the block header - which isn't there, and it asserts. This wouldn't work anyway, because the debug and release CRT use different DLLs, but I didn't think about that at the time.
So, my next solution was to use malloc() and free() instead, for the script var. Same problem.
So, my (rather icky) solution is to get a pointer to the free() function whenever I call malloc() and store it as a member variable. Then I use that function pointer to free the memory, which will call free() from the same place as malloc() was done. I'm fully expecting this to come back and bite me in the ass, but I can't think of anything wrong with this approach (Aside from using malloc() and free() in C++).
The reason for all this was to move the Lua stuff into a DLL. That brings my release EXE size down from 285KB to 160KB, allows me to run my client without a scripting system in it (Although most of the cool stuff comes from the script system), or to use other scripting languages instead of, or as well as Lua.
