Sign in to follow this  
GenuineXP

Using the STL Between Binaries

Recommended Posts

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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
A few options,

1) Ensure all modules/apps are compiled with same compiler/STL implementation. This is really not that difficult if your dependancies dont use STL, just those which use STL.

2) Pass it as an array or non-STL construct.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this