I'm wondering if anyone has advice about using the STL between programs (that may be compiled separately and therefore possibly with a different STL implementation). Presently, my engine uses a module plugin system that sits below the core's abstraction. The input system asks the module each cycle for any input events that have occured. These events are stored in a std::vector, and for each event that's placed in the std::vector (by the module) a signal is fired. The problem is, I've heard that it's generally a bad idea to pass around STL constructs between binaries because differing implementations may not work together properly and could cause crashing or abnormal behaviour. If this is the case, how should I approach this? Should I completely scrap the std::vectors, or is there a way to safely expose the raw data to the module? Is this really even a problem? Even if an STL implementation is different, I'm doing simple operations with a standardized interface; will it really break? Any advice is appreciated. Thanks!

STL is not well suited for what you want to do. A large part of why .NET even exists is to solve the questions you ask. Never expose STL based data unless you intend it to be used with a specific revision of a service pack of a specific version of a specific compiler. They really are that incompatible, you're not even guaranteed compatible implementations within the same compiler.

I don't exactly understand what you're doing. If you have a vector<int>, you can 'send' that to another program by serializing a stream of ints - on the other end, you can add them to a vector<int> in that program with no problem at all. Do you think you'll be able to accomplish the same thing by copying the raw memory of the vector<int> object and just sending that across? That generally won't work for any object except primitives, and has nothing to do with standard library implementations.

Or do you mean you've compiled a DLL with exported functions like void foo( std::string ); and you want to pass a string into the DLL? Yes, you can run into major problems if you're not compiling against the same idea of std::string, and you also have to worry about memory allocation and deallocation issues across DLL boundaries.

One thing I thought of is to serialize and deserialize the vector.

How it can be passed between the 2 programs I am not sure. You could open a port to listen. Or had a common database they can read from.

Thanks for the replies, everyone.

Thinking about it, I don't think having to compile both the core and module(s) with the same compiler and STL package is really that harsh of a constraint. However, for the time being I removed the vectors and went with built-in arrays instead. This added additional parameters, of course, and since I didn't want to deal with dynamic reallocation it has also imposed a size limitation.

I'm interested in how I would serialize a container to pass between programs. The first thought I had when I read that idea was too copy the data manually into a chunk of memory and pass that to the module which would stuff it into it's own vector, work with it, and then copy that data again for the core to load back into it's vector. This sounds very, very inefficient though, especially since this process happens once every cycle for several kinds of events. Or am I just getting this idea all wrong? :-)

Thanks again. Any more insight is welcome.

Not all arrays are safe. You may get memory padding issues in between elements. Same with any complex types. Look at the way COM works and do interop in a similar fashion or pick a more reflective environment.

The restriction you mentioned is much harsher than you think, imagine if Microsoft releases a service pack, you might have integration issues across the team or across various software packages because everyone is running their own version.

Tbh passing around interfaces in the manner COM does is probably your best bet and it's much cleaner. Serialization to a common binary format is another but it will make calls across module boundaries extremely expensive.

Good points, thanks for the insight. :-)

Keeping this in mind, I plan on adding an event_queue interface (much like the other interfaces used to communicate with the module) that accumulates events the core wants to know about. This should help solve the problem of passing raw data around.