Re: SysAllocString
George wrote:
Thanks Igor,
>
allocators. E.g. when the two were built with different compilers, or
with different versions of the same compiler, or even with the same
version but they link to CRT statically (as opposed to CRT DLL).
I can understand that if we staic link to CRT, there will be troubles. But
if we dynamic linking to CRT (as what we usually do), when we run the program
(EXE and the DLL inside), the runtime (not the compile time/link time one)
CRT memory allocator/deallocator will be invoked. Since in runtime, there
will be only one copy of allocator/deallocator, I do not understand why there
will be allocator incompatible issues.
As Igor wrote, there won't be an issue.
If you use the same compiler version to build the EXE and the DLL, and both link
dynamically to the runtime library, then you are fine.
You can get into trouble if
* the EXE and the DLL are build with different compilers or even compiler
versions (because the EXE might load version A of the DLL runtime and the DLL
loads version B of the runtime)
* the EXE or the DLL statically link to the runtime library.
This thread was ariginally about SysAllocString. The main purpose of this
function is to allocate string data that needs to be marshalled from one COM
component to another one. The COM runtime system needs to be able to access,
allocate and free this type of memory to move the data between process or
computer boundaries.
If you stay within your own process, calling DLL functions by "plain" function
calls, you will be safe with just new/delete. If you have full control over all
EXE and DLL components if youjr project, then you can safely move memory around
between the DLL and the EXE. If the DLL and EXE are buuild independent of each
other, then it is safer to rethink the DLL interface in a way that the ownership
of memory does not move between the modules. Or, for the more experienced C++
developer, only pass objectes that use a custom allocator.
Norbert