Memory Management concerns

["Dunko, Greg" <Gr...@FMR.COM>]

Hi all,

I'm new to the Xalan world and I'm trying to discern some information that
the documentation doesn't seem to address.  One of my concerns is with the
ownership and lifecycle of the different objects that are returned from the
Xalan library.  I'm doing transformations that are returning output in a
XalanDocument.  The documentation does state that this object is owned by
the library.  Calling destroyDocument can ensure it goes away cleanly when
no longer needed.  I'm concerned about the other calls though.

For example, when I call getFirstChild I get a node pointer.  Who owns that
object?  Will it live as long as the XalanDocument?

When I make a call that returns a NodeList, who owns this structure?  How
many of these structures can I be working with at one time?  Does the
library own and reuse one of them or are there multiples?  If it's creating
them on the fly, how can I ensure these are cleaned up when I'm done with
them as opposed to when the document is destroyed or the call to terminate()
is made?

Lastly, the semantics for the methods in XalanNode are fairly vague.   If I
were to call getFirstChild() on a XalanElement I can then call
getNextSibling() on the resulting XalanNode to iterate through the nodes at
that level in the document?   What constitutes a node vs. an element?  Are
attributes included in the chain of nodes that are accessed in this process?
I can't see the difference between getNodeName and getTagName,etc.

Sorry for so many questions, but as you can see I'm finding the docs a
little sparse so I need some perspective on the assumptions this API makes.
Is there a more descriptive set of docs for the Xalan DOM api that I'm
missing somewhere?  Perhaps someone can point me in the right direction :)

Thanks!

--
Greg Dunko
Fidelity Investments
603.791.8216
mailto:greg.dunko@fmr.com

Re: Memory Management concerns

[David N Bertoni/Cambridge/IBM <da...@us.ibm.com>]

"Dunko, Greg" <Gr...@FMR.COM> wrote:
> I'm new to the Xalan world and I'm trying to discern some information
that
> the documentation doesn't seem to address.  One of my concerns is with
the
> ownership and lifecycle of the different objects that are returned from
the
> Xalan library.  I'm doing transformations that are returning output in a
> XalanDocument.  The documentation does state that this object is owned by
> the library.  Calling destroyDocument can ensure it goes away cleanly
when
> no longer needed.  I'm concerned about the other calls though.

This is not necessarily true.  If you do the following:

   XalanDocument* const   doc = new XalanSourceTreeDocument;

Then you will have to delete the instance yourself, because you created it
explicitly.

However, if you do:

   XalanDocument*
   parse(
       XalanSourceTreeParserLiaison&  thePL,
       const InputSource&             theIS
   {
       return thePL.parseXMLStream(theIS);
   }

Then the XalanSourceTreeParserLiaison instance owns the document and will
destroy it explicitly through a call to
XalanSourceTreeDocument::destroyDocument(), or implicitly when it (the
XalanSourceTreeParserLiaison instance) goes out of scope.

This is the fundamental philosophy almost everywhere in the library: if you
explicitly create something through the new expression, you must delete it.
Otherwise, it will be managed by something, and you don't have to worry
about it.  Off the top of my head, I can't think of anywhere this is not
the case.

> For example, when I call getFirstChild I get a node pointer.  Who owns
that
> object?  Will it live as long as the XalanDocument?

yes and yes

> When I make a call that returns a NodeList, who owns this structure?  How
> many of these structures can I be working with at one time?  Does the
> library own and reuse one of them or are there multiples?  If it's
creating
> them on the fly, how can I ensure these are cleaned up when I'm done with
> them as opposed to when the document is destroyed or the call to
terminate()
> is made?

The XalanDocument instance owns it.  There is only one instance, although
it's not anything you even need to worry about.  There is nothing to clean
anything up, because the XalanDocument instance controls any resources
required.

> Lastly, the semantics for the methods in XalanNode are fairly vague.   If
I
> were to call getFirstChild() on a XalanElement I can then call
> getNextSibling() on the resulting XalanNode to iterate through the nodes
at
> that level in the document?   What constitutes a node vs. an element?
Are
> attributes included in the chain of nodes that are accessed in this
process?
> I can't see the difference between getNodeName and getTagName,etc.

You need to understand the W3C DOM, because Xalan's DOM has the same
semantics:

   http://www.w3.org/TR/DOM-Level-2-Core/

Just a note on performance -- in Xalan's default implementation, it's
better to use getFirstChild()/getNextSibling() to traverse the tree.
Calling XalanNode::getChildNodes and using the XalanNodeList instance
returned is much less efficient.

Dave