It seems as though the cleaner  way to solve this problem is to provide a
function from within the .DLL which de-allocates the memory allocated by the
.DLL.  This gets rid of compiler run-time errors such as threading,
debugging, statically dynamically built libraries, etc.

My own personal  rule is, anytime a .DLL allocates ANY memory, provide a
means to free it (this after many years of using C++ Builder on top of
Visual C++-built .DLLs).



----- Original Message -----
From: "Jesse Pelton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 20, 2001 11:45 AM
Subject: RE: Deleting char* returned from DOMString.transcode() in VC++ 6. 0


> Yes. I'm trying to understand something that has come up in the past. Dean
> has suggested that people should look at the list of DLLs brought in by
> their program to see if the wrong runtime is getting brought in. (I just
did
> the same thing, but I'm trying to figure out whether that was helpful in
> this case.) It seems to me that having two versions of the runtime
shouldn't
> be a problem as long as the code that frees the memory allocated by
> transcode() is linked against the same version of the runtime as Xerces.
>
> So, if my_processor.exe links against the debug version of Xerces and the
> multithreaded debug DLL version of the runtime, everything should be cool,
> even if (say) ws2_32.dll brings in the retail runtime.
>
> If that's the case, I don't understand the usefulness of inspecting the
list
> of DLLs used (with Depends, chkmod32, or some other utility). I guess this
> is really a question for Dean, in whose hallowed footsteps I blindly (that
> is to say, ignorantly) trod. But if someone else can open my eyes, I'd be
> equally grateful.
>
> > Doesn't the problem only occur when memory is allocated in one runtime
and
>
> > freed by another?  Many libraries intentionally force memory to be
> > allocated and deallocated in the same place (either by the caller or the
> > callee).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to