Anthony Williams wrote:

> >Hmm, just to check whether we are still talking about the same thing here:
> >do we agree that there can't be a 'node' type, i.e. just a
> >'node_ref'/'node_ptr' ?
>  
>  
>  You mean: have "node" as an abstract class, so you can't have any objects of
>  that type, but you can have pointers and references? Sounds good.
>  
>  What's wrong with just having boost::shared_ptr<Document> and
>  boost::shared_ptr<Node>, boost::shared_ptr<Element> ?

no, I was alluding to the fact that in my case nodes are fully managed 
their parent. That implies that I can't have free floating nodes, i.e. 
outside the document tree. Well, I probably could but that would put the
burden of managing the memory on the programmer's shoulders, while with
the current model all memory is managed by libxml2.

That's why I'm suggesting _ptr/_ref types in the first place. The
expression

dom::node_ptr parent = current.parent();

will return a reference to the parent node, i.e. it will create
a temporary reference object, who's lifecycle is fully decoupled from
the lifecycle of the actual node (who is managed by the document tree).

>  You could have each node store a boost::weak_ptr<Element> pointing to its
>  parent, which is converted to a boost::shared_ptr<Element> when you ask for
>  it. That way, a child doesn't keep its parent alive (though parents should
>  keep their children alive), but you can still traverse up the tree if you
>  like.

yes, when reimplementing a dom tree from scratch that may be an option.
But as I said, I'm wrapping a C XML library that already does most of
the work for me, and I'm trying to make the wrapper objects as
lightweight as possible.

Regards,
		Stefan



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost