One way is to extend the allocator to provide a way to validate a pointer. The allocator has a list of large memory blocks which is chopped up into smaller bits when needed. It is a simple task to check if a pointer is contained inside a block. But that requires that the allocator is global. The one right now works on a document level. Each document has an allocator. When I think about it a global object that contains references to all allocators still active in the system and a call on the allocator to check a pointer would do it.
/ Erik > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: den 14 juli 2003 22:03 > To: [EMAIL PROTECTED] > Subject: Re: parser->parse() question > > > Exactly ;-) > > Thanks for the help! > > BTW, I asked this in a different thread (probably poor etiquette), and got > the UserData answer. However, I'll bring it up again here since it is > related....is there any other way to tell if a node is still in memory or > valid? I would like some sort of derefence mechanism to just do a simple > check before trying to act on a node/doc/etc. It would be nice to perform > this check to avoid unexpected crashes (always fearful that resources may > be 'released' under my feet). I keep coming back to this b/c I have a > pseudo-wrapper around each DOM class, which means I have my own pointer to > each object. I am trying to avoid a situation where a release frees a > Xerces pointer without my pointer realizing it. I could possibly use > UserDataHandler, but that is quite cumbersome....a simple validity check > would be nice. > > DOMNode *doc = parser->getDocument(); > DOMNode *docel = ((DOMDocument*)doc)->getDocumentElement(); > > // then somewhere else in the app > if (**docel) > docel->dosomething(); > > Thanks again. > > > > > |---------+----------------------------> > | | "PeiYong Zhang" | > | | <[EMAIL PROTECTED]| > | | ibm.com> | > | | | > | | 07/14/2003 02:54 | > | | PM | > | | Please respond to| > | | xerces-c-dev | > | | | > |---------+----------------------------> > >----------------------------------------------------------------------- > -----------------------------------------------------------------------| > | > | > | To: <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> > | > | cc: > | > | Subject: Re: parser->parse() question > | > >----------------------------------------------------------------------- > -----------------------------------------------------------------------| > > > > > But resetPool() is proected, so i guess u shall call resetDocumentPool() > instead. > > Rgds, > PeiYong > ----- Original Message ----- > From: "Erik Rydgren" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, July 14, 2003 3:50 PM > Subject: RE: parser->parse() question > > > > I think it is the same call. I was looking at the AbstractDOMParser > > interface. I think resetDocumentPool calls resetPool. But I'll check the > > source too be sure...... *muffled noices* > > > > Yepp! It is the same call. > > > > / Erik > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Sent: den 14 juli 2003 21:38 > > > To: [EMAIL PROTECTED] > > > Subject: RE: parser->parse() question > > > > > > > > > Would it acceptable to use resetDocumentPool()? Or is resetPool() > > > superior > > > in some way? > > > > > > > > > > > > > > > > > > |---------+----------------------------> > > > | | "Erik Rydgren" | > > > | | <[EMAIL PROTECTED]| > > > | | darinen.se> | > > > | | | > > > | | 07/14/2003 01:32 | > > > | | PM | > > > | | Please respond to| > > > | | xerces-c-dev | > > > | | | > > > |---------+----------------------------> > > > > > >----------------------------------------------------------------------- > > > > > -----------------------------------------------------------------------| > > > | > > > | > > > | To: <[EMAIL PROTECTED]> > > > | > > > | cc: > > > | > > > | Subject: RE: parser->parse() question > > > | > > > > > >----------------------------------------------------------------------- > > > > > -----------------------------------------------------------------------| > > > > > > > > > > > > > > > Gareth, you forgot to mention that the first document is still valid > > > after a reset. The parser keeps the document in an internal list until > > > the parser is deleted or the method resetPool is called on the parser. > > > > > > Do a reset before each parse and smile just like Gareth says unless > > you > > > REALLY want to kill the document and get the resources back, then call > > > resetPool instead. Mind that resetPool deletes ALL documents created > > by > > > that parser. If you want to control which documents that gets deleted > > > then you'll have to adopt each parsed document and delete them > > yourself. > > > > > > / Erik > > > > > > > -----Original Message----- > > > > From: Gareth Reakes [mailto:[EMAIL PROTECTED] > > > > Sent: den 14 juli 2003 19:41 > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: parser->parse() question > > > > > > > > Hi, > > > > > > > > > So, what is my question? What is the status of these nodes "left > > > over" > > > > > from the first parsing? I thought they would be orphaned, but > > > > apparently > > > > > not. > > > > > 1. Am I responsible for releasing them? > > > > > > > > You should call reset between parses. If you do this then the parser > > > will > > > > delete the docs for you. If you don't then things can go bad. > > > > > > > > > 2. If they still see the doc as their parent node, why don't they > > > show > > > > up > > > > > when the node is printed? > > > > > > > > The nodes from the first parse will see the first doc as their > > parents > > > and > > > > the nodes from the second the second. > > > > > > > > > > > > > 3. Exactly what is the status of these nodes? > > > > > > > > Nodes that have been created but are no longer the parsers > > > responsibility > > > > to delete. > > > > > > > > > > > > Summery - call reset between parses and smile :) > > > > > > > > Gareth > > > > > > > > > > > > -- > > > > Gareth Reakes, Head of Product Development +44-1865-203192 > > > > DecisionSoft Limited > > > http://www.decisionsoft.com > > > > XML Development and Services > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
