r for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Arnold, Curt" <[EMAIL PROTECTED]> on 01/26/2000 08:19:06 AM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Xerces bug submission...
Unfortu
Unfortunately, I think leaks will be a continuing source of complaints,
especially as the code base gets into to more applications. Making an
uninitialize method available (which could be called from global object
destructors) that releases resources and restores each and every static back
to null
TECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Xerces bug submission...
Dean Roddey wrote:
For use, its mainly the inderminant order or creation and destruction.
There is no good way, that is portable, to make sure that things get
created and cleaned up in the right order. This is pa
Dean Roddey wrote:
For use, its mainly the inderminant order or creation and destruction.
There is no good way, that is portable, to make sure that things get
created and cleaned up in the right order. This is particularly sticky in
the case of the objects that were in question in this topic, e.g.
PROTECTED]
"Arnold, Curt" <[EMAIL PROTECTED]> on 01/25/2000 10:54:28 AM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Xerces bug submission...
Dean Roddey wrote:
>>We cannot use any sort of glob
Dean Roddey wrote:
>>We cannot use any sort of global object destruction to clean them up, ...
I'm really curious to know what the issues are driving avoidance of global
objects for static resources. Is it a platform issue, the indeterminent
order, or something else?
"XMLAttr.cpp: fPrefix is allocated & never destroyed."
If this was true at one point, it isn't anymore. I believe that it was
fixed for the 1.0.1 release, but it is definitely fixed in the newest code.
"XMLScanner2.cpp: XMLPlatformUtils::getBasePath() returns a string which is
not destroyed."
Thank you for Xerces, the team I develop on have been using Xerces since its'
release & have had been quite satisfied with it. Well done!
We have recently compiled our project using Rational Purify & have discovered
several memory allocations which remain unreleased when the dll terminates.
