Re: question about CRT boundries
From: thePoet (thepoet_usenet_at_dfsoftware.com)
Date: 03/06/04
- Next message: Graeme: "Re: basic_string ref across dlls"
- Previous message: Orhun Birsoy: "Re: basic_string ref across dlls"
- In reply to: Igor Tandetnik: "Re: basic_string ref across dlls"
- Next in thread: Carl Daniel [VC++ MVP]: "Re: question about CRT boundries"
- Reply: Carl Daniel [VC++ MVP]: "Re: question about CRT boundries"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 06 Mar 2004 21:18:09 GMT
> CAtlString uses HeapAlloc et al for memory management, using process
> default heap.
There is something I'm missing in all this discussion, which is, what
causes an allocation to be run in one version of the CRT versus another.
Here is an example that I know doesn't have problems. I will then
contrast it with the string example to try to find out where the
diference lies. Please, everyone, fill in my knowledge gaps, cecause
something isn't adding up for me.
Working example:
I have often developed classes that were defined in one dll and passed
into another. One example is our DynamicTableType. This object is
defined in a utility dll, created in the application, and then passed
into plugins (its in the utility to make it easier for plugin
development). The plugins make a series of calls into the
DynamicTableType that onternally causes it to allocate and sometimes
memory internally. When the DynamicTableType is deallocated by the
application, its creator, there are no memory issues. All the
allocationa and deallocations take place in the same CRT instance, even
though often time the CRT instance of the plugin is completely different
than that of the application.
Failing example:
I create a basic_string in the executable, pass it into dll that runs in
a different CRT. That dll makes a call that causes it to internally
allocate memory. The string is returned to its creator and deallocated,
and the system crashed because the internal memory of the string was
created in another CRT instance.
To sum up:
What is the difference between the two situations. Is the memory
allocation problem caused by the dll knowing the code of basic_string
and thus triggering it in the scope of the library instead of the scope
of the location it was created in? Is the only reason that the first one
works is because the plugin doesn't know how to execute DynamicTableType,
so it must call back into the library it was defined in? If so, doesn't
this make coding any template that will be passed across boarders
without using HeapAlloc(GetProcessHeap()...) extremely dangerous?
- Next message: Graeme: "Re: basic_string ref across dlls"
- Previous message: Orhun Birsoy: "Re: basic_string ref across dlls"
- In reply to: Igor Tandetnik: "Re: basic_string ref across dlls"
- Next in thread: Carl Daniel [VC++ MVP]: "Re: question about CRT boundries"
- Reply: Carl Daniel [VC++ MVP]: "Re: question about CRT boundries"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|