Re: DLLs and Sharing Memory
Jimmie <oskard@gmail.com> wrote:
I have an application, and a DLL. The application was linked to the
DLL via a .lib file, and was accessing the exported functions just
fine. One particular example of the relationship was this:
void _stdcall GetHosts(vector<string> * vszHostsD);
// In which the DLL would require a pointer to a vector<string> as
input, and modify its contents.
This can only work if both the EXE and the DLL are compiled with the
same version of the same compiler using the same options, and linked to
the same flavor of CRT DLL. It won't work if you link to CRT statically.
// And the application would call this function in the appropriate
way:
vector<string> * vszHosts;
GetHost(vszHosts);
MessageBox(...vszHosts.at(0).c_str()...); // The contents of the
vector were filled correctly
This can't possibly compile. Did you mean
vector<string> vszHosts;
GetHost(&vszHosts);
?
My original configuration was this:
Configuration Properties -> C/C++ -> Code Generation -> Runtime
Library == /MD
I followed some advice, and changed this value to /MT
Wrong move. /MT means linking to CRT statically, which results in EXE
and DLL each having a separate copy of memory manager. Memory allocated
in one module cannot be freed in another. /MD was a correct choice
(still better choice would be to redesign the DLL interface so it
doesn't require passing resource ownership between modules).
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925