You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Earthlink Mail <se...@earthlink.net> on 2001/04/20 19:12:40 UTC
Re: Deleting char* returned from DOMString.transcode() in VC++ 6. 0
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" <js...@PKC.com>
To: <xe...@xml.apache.org>
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: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Deleting char* returned from DOMString.transcode() in VC++ 6. 0
Posted by Dean Roddey <dr...@charmedquark.com>.
We wouldn't want to do that. If your application is keeping the data around,
its very convenient and efficient to be able to just call this method and
get back something you can store. I don't think we need to make life harder
for those folks who understand the issues, in order to protect people who
don't.
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com
"Why put off until tomorrow what you can
put off until the day after tomorrow?"
----- Original Message -----
From: "Bill Schindler" <de...@bitranch.com>
To: <xe...@xml.apache.org>
Sent: Saturday, April 21, 2001 11:54 AM
Subject: Re: Deleting char* returned from DOMString.transcode() in VC++ 6. 0
> > 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.
>
> The cleanest solution would be to remove DOMString::transcode()
> from the public API. There are other ways of transcoding that don't
> leak memory, have better control over transcoding, and don't
> produce run-time errors.
>
> --Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Deleting char* returned from DOMString.transcode() in VC++ 6. 0
Posted by Bill Schindler <de...@bitranch.com>.
> 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.
The cleanest solution would be to remove DOMString::transcode()
from the public API. There are other ways of transcoding that don't
leak memory, have better control over transcoding, and don't
produce run-time errors.
--Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org