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 Jeff Lewis <jd...@xactware.com> on 2000/04/14 16:09:59 UTC
RE: Bug 106, requires statically linking as workaround
What we have done here - only because I cannot convince everyone to use
debug allocation - is create two global functions in the Xerces dll that are
then used to delete anything allocated by Xerces:
#define XercesDelete(ptr) _XercesDelete(ptr); ptr=0;
#define XercesDeleteArray(ptr) _XercesDeleteArray(ptr); ptr=0;
void _XercesDelete(void *pVoid)
{
delete pVoid;
}
void _XercesDeleteArray(void *pVoid)
{
delete [] pVoid;
}
These functions, along with the macros, avoid any of these problems... It
also lets us mimic what we have been doing for years in our other code with
our own custom NEW and DELETE operators/functions - You can do a lot of
memory leak debugging by overriding these operators, plus when I delete
something, I know that I will never use that pointer to it again because it
is already NULL. (At least not without terrible heartache!)
-----Original Message-----
From: Juergen Hermann [mailto:jhe@webde-ag.de]
Sent: Friday, April 14, 2000 3:15 AM
To: xerces-c-dev@xml.apache.org
Subject: RE: Bug 106, requires staticly linking as workaround
On Thu, 13 Apr 2000 13:41:05 -0700, James Fowler wrote:
>There are two practical ways to deal with this.
No, 3 ways. :)
3. [static] void DOMString::free(const char* transcoded_str)
{ delete[] transcoded_str; }
That does not break existing code that calls delete[] directly, and helps
all other issues w/o any large effort.
[NB: instead of free() one might prefer destroy() or anything similar]
Ciao, Jürgen
--
Jürgen Hermann (jhe@webde-ag.de)
WEB.DE AG, Amalienbadstr.41, D-76227 Karlsruhe
Tel.: 0721/94329-0, Fax: 0721/94329-22
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Bug 106, requires statically linking as workaround
Posted by Daniel Schroeder <da...@mozquito.com>.
I'm very new to this list (hello, everybody! :-)), and just starting to find
my way around in Xerces.
However, from past C programming experience, I feel that the two defines
should read
#define XercesDelete(ptr) {_XercesDelete(ptr); ptr=0;}
#define XercesDeleteArray(ptr) {_XercesDeleteArray(ptr); ptr=0;}
Otherwise a piece of code like
if(/* some condition evaluating to false */)
XercesDelete(ptr);
would still set ptr = 0, which is definitely not what one would expect.
Daniel
-- ------------------------------
Daniel Schröder (daniel@mozquito.com)
Senior Software Engineer
Stack Overflow AG
-----Original Message-----
From: Jeff Lewis [mailto:jdlewis@xactware.com]
Sent: Friday, April 14, 2000 4:10 PM
To: 'xerces-c-dev@xml.apache.org'
Subject: RE: Bug 106, requires statically linking as workaround
What we have done here - only because I cannot convince everyone to use
debug allocation - is create two global functions in the Xerces dll that are
then used to delete anything allocated by Xerces:
#define XercesDelete(ptr) _XercesDelete(ptr); ptr=0;
#define XercesDeleteArray(ptr) _XercesDeleteArray(ptr); ptr=0;
void _XercesDelete(void *pVoid)
{
delete pVoid;
}
void _XercesDeleteArray(void *pVoid)
{
delete [] pVoid;
}
These functions, along with the macros, avoid any of these problems... It also lets us mimic what we have been doing for years in our other code with our own custom NEW and DELETE operators/functions - You can do a lot of memory leak debugging by overriding these operators, plus when I delete something, I know that I will never use that pointer to it again because it is already NULL. (At least not without terrible heartache!)
-----Original Message-----
From: Juergen Hermann [mailto:jhe@webde-ag.de]
Sent: Friday, April 14, 2000 3:15 AM
To: xerces-c-dev@xml.apache.org
Subject: RE: Bug 106, requires staticly linking as workaround
On Thu, 13 Apr 2000 13:41:05 -0700, James Fowler wrote:
>There are two practical ways to deal with this.
No, 3 ways. :)
3. [static] void DOMString::free(const char* transcoded_str)
{ delete[] transcoded_str; }
That does not break existing code that calls delete[] directly, and helps
all other issues w/o any large effort.
[NB: instead of free() one might prefer destroy() or anything similar]
Ciao, Jürgen
--
Jürgen Hermann (jhe@webde-ag.de)
WEB.DE AG, Amalienbadstr.41, D-76227 Karlsruhe
Tel.: 0721/94329-0, Fax: 0721/94329-22
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org