Problem retuning a vector from a c++ dll to another c++ exe

Question

Hi,

I have a function foo() in dll A.dll, whose definition is as follows

vector<CustomObject> foo()  
{   
      vector<CustomObject> customObjectCollection;

   //code which populates customObjectCollection goes here

return customObjectCollection;   
}

I am referring this method vector foo() of dll A from exe B

When i make a call to the function foo from B, I get an unhandled exception which says

"unhandled exception at 0x10487b3f(msvcp90d.dll) in B.exe" 0xC0000005: Access violation while writing to the location 0xfdfdfdfd".

Note:type CustomObject does not implement copy constructor

When i tried to debug by attaching B.exe to A.dll, I found that inside method vector foo(), the vector gets populated without any problem but when the control returns to B.exe the valves in vector doesnot get copied !!!

Also, if method foo returns vector by reference , exception doesnot occur and B.exe receives an empty vetor.

what is the issue ?? Is it happening as I have not implemented copy constructor for CustomObject.

Any help is greatly appreciated (Apologies for not articulating the question properly)

Thanks
jeel

Answer 1

Probably the safest way would be:

bool foo(vector<someclass*> &customObjectCollection)
{
    //code which populates customObjectCollection goes here

    return success
}

This way the calling program creates and maintains the vector so there's no need for copying. Caller would do

vector<someclass *> customObjectCollection;
foo(customObjectCollection);

Also, depending on what you are doing exactly, note the use of a vector of someclass pointers rather than someclass objects.

Answer 2

First of all you should not return references to local objects declared on stack. Second: there are requirements for elements to be able to be used in STL containers
1) Copy constructor
2) Assignment operator
3) Public destructor
There are more container specific (like sorting criterium for associative containers).
Copy constructor will be created as well as assignment operator (thanks to the compiler) so unless you explicitly hide them - your object has them (if you did not have copy constructor, compiler would complain).
But these implicit copy constructor and assignment operator may not be smart enough, so you may want to implement your own. For instance: lets say that you CustomObject in constructor creates an instance of some class with new and keep it as pointer to be destroyed in the destructor. Default copy constructor will make a shallow copy, so this will result in two objects holding the same pointer. Once one of them is destroyed, second one becomes inconsistent (it holds pointer that has already been released).

Final note: try not to return vector by value. A lot of copying is involved. Declare it in the caller on stack and pass it as reference to you foo.

Answer 3

This is a classic symptom of mismatched runtime libraries. You have to make sure that both the EXE and the DLL are linked to the dynamic C++ library (DLL version).

If one (or both) are linked with the static C++ runtime (LIB version), you'll get memory violations since there will be two instances of the runtime library with different address spaces.

Answer 4

There are a number of possibilities here, and you haven't told us enough to determine which is most likely to apply.

One possibility is (semi-)unique to putting the code in a DLL. If you link the standard library statically, each module (EXE, DLL) gets its own memory management, including its own heap, so quite a few operations that try to transfer ownership of memory between one module and another will fail for (seemingly) strange reasons. The cure for this type of problem is usually to link to the standard library in a DLL for all your modules. This gives one copy of the standard library shared throughout the application, so passing ownership between modules doesn't cause a problem.

Another possibility is that your CustomObject class isn't handling copying appropriately. Since you've told us nothing about its internals, it's impossible for us to guess what you might need to do here.