Re: [Libxmlplusplus-general] parametrizing libxml++ for the character /string type

[murrayc t-online de (Murray Cumming)]

On Wed, 2003-01-29 at 05:52, Stefan Seefeld wrote:
> ok, here is the first patch.

In general, patches should go into the sourceforge patch manager.

>  The goal was to change the implementation to
> delegate whatever we can down to libxml2, while respecting the existing API.
> 
> So, everything compiles, and the examples run unchanged.

That sounds good.

> There are, however, a couple of issues which need to be addressed. I hope we can
> sort them out together. First a little account on what this change does:
> 
> All libxml2 structures use '_private' members for application data. I use that
> to point to the corresponding libxml++ wrapper class, so we can do a reverse
> lookup. For example, to access the first child node of a xmlpp::Node object,
> you'd do something like:
> 
> reinterpret_cast<Node *>(this->_impl->children->_private)

It should probably be a static_cast<> if _private is a void*, but it's
not a big deal.

So, we create new xmlpp::Nodes to wrap each xmlNode, but when do those
xmlpp::Nodes get deleted?

> Easy enough, isn't it ?
> 
> The tricky point is, as said earlier, ownership management. libxml2's nodes
> are owned by their parent nodes (and ultimately by the enclosing document),
> not by the libxml++ wrapper object. We need to work out how transfer of ownership
> should happen when a node is unlinked from its document / parent node.

Is there any way to get notification of this?

> 
> Another tricky point is that libxml2 will automagically merge nodes occasionally,
> for example if you insert a new text node right after an existing text node.
> Thus,
> 
> Node *Node::add_child(const std::string &)
> 
> may or may not return a new object. It is, however, (and luckily,) owned by the
> parent node, so the caller doesn't have to care. A similar argument is to be made
> for setting attributes.

-- 
Murray Cumming
murray usa net
www.murrayc.com