I've returned vectors (and other STL types) across DLL/shared library boundaries loads of times and not had a problem.
EXCEPT when compiler settings were a lot different
OR the DLL was compiled with another compiler in which case all bets are off.
As I found your code in the comment a bit hard to parse this
might (CAVEAT, code completly untested, normally I don't do this but I'm using a computer without MFC on it [1]) be workable as a way of serialising a vector into an archive:
template<typename type_to_store>
CArchive &operator<<(
CArchive &archive,
const std::vector<type_to_store> &to_store )
{
typedef std::vector<type_to_store>::const_iterator iterator;
for(iterator iter = to_store.begin(); iter != to_store.end(); ++iter )
archive << *iter;
return archive;
}
Hopefully any compiler errors should be easy to sort out. If that doesn't work with both applications then you've got two apps that have used significantly different compiler settings to build and the only way around it is to try and work out how to converge them.
Cheers,
Ash
[1] I've only got VC++2010 express which doesn't come with MFC.
Added guff (16/04/12)
It sounds like your problem is that no guarantee that generally you can link C++ code that's compiled with two different compilers. Sometimes you can get away with it especially if you only pass pure (no implementation code or abstract) interface classes - i.e. all the code for the class is either in the DLL or it's in the calling EXE.
If it's not then the binary layout of the object can be different on either side of the EXE/DLL boundary as different compilers compile the same code in different ways AND the vendor might have changed the implementation of the class. MS have had to maul their standard library a fair bit to make it comply to the C++11 standard between VC++2008 and 2010. Where the code compiled with 2010 expects to find the vector's data pointer the code compiled with 2008 compiler might have stuck the size at the same address, the implementations swapping the data members around for some reason them around for some reason.
So, what can you do about this then?
The first thing you can try is pass an abstract class that contains a vector<whatever> and exports a couple of pointers to the start and end of the vector.
An interface like:
class vector_int_marshaller
{
public:
virtual int *start_of_vector() const = 0;
virtual int *end_of_vector() const = 0;
};
And implement it on the DLL (VC++2005) side:
class vector_int_marshaller_imp : public vector_int_marshaller
{
public:
vector_int_marshaller_imp( const std::vector<int> &to_marshal ) : to_marshal_( to_marshal )
{
}
virtual int *start_of_vector() const
{
return &to_marshal_[0];
}
virtual int *end_of_vector() const
{
return start_of_vector + to_marshal_.size();
}
private:
const std::vector<int> &to_marshal_;
};
And finally convert it into a VC++2010 vector in the EXE:
std::vector<int> data( vec->start_of_vector(), vec->end_of_vector() );
You can get away with this as you're only using built in types AND a v_table, which MS have to keep in a certain format as they still support COM (ho, ho, ho :-) ).
Having said all that the best thing to do is grab every bit of C++ code you use and compile it with the same compiler. Absolutely everything that doesn't have a pure C interface.
Hope the additions help, I missed the point that you were building with multiple compilers before,
Ash
Edit: Corrected a few typos and unclear bits of text
EditII: Punctuation fail, rewrote a chunk of it to try and make it clearer. grr...
Edit III: Just noticed some stray guff the editor left lying around