ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> boost
boost
[boost] Re: API Review request: XML API for C++, second round
by Anthony Williams other posts by this author
Jun 27 2003 11:53AM messages near this date
[boost] API Review request: XML API for C++, second round | Re: [boost] Re: API Review request: XML API for C++, second round
Hamish Mackenzie <hamish@[...].uk>  writes:

>  On Fri, 2003-06-27 at 09:09, Anthony Williams wrote:
>  > What's wrong with just having boost::shared_ptr<Document> and
>  > boost::shared_ptr<Node>, boost::shared_ptr<Element> ?
>  > 
>  > 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.
>  > 
>  > You could do the same for documents --- the document holds a shared_ptr to
>  > the root element, and so keeps the whole tree alive. Each element holds a
>  > weak_ptr to the document, so you can retrieve the document from it, but it
>  > doesn't keep it alive. Consequently, if you erase an element from the
>  > document, but you still have a pointer to it, then the element itself is
>  > OK, but it will then die when your pointer goes out of scope. Also, if the
>  > document goes out of scope, then your element is still OK, but is no
>  > longer associated with a document.
>  
>  This sounds like a description of an implementation rather than the
>  interface.  This implementation would not solve the problem "what is a
>  node when it is not part of document?".

It was meant to be a description of semantics, in terms of a sample
implementation.

A node that is not part of a document is a free-standing subtree that needs
adding to a document. If it is an element, then you can treat it as if it is
the root node of a document. If it is anything else, then you are more limited
in what you can do, but then what does it mean to perform an XPath query on a
PI?

If the underlying API requires that the document is kept alive to keep the
nodes alive, then the wrapper class must handle this, whilst simulating the
above semantic description.

>  Your implementation would be much easier to wrap than libxml2.  You
>  could implement the same interface simply with...
>  
>  typedef Document document;
>  typedef Node * node_ptr;
>  typedef Node & node_ref;
>  
>  The problem when wrapping libxml2 is that the node is stored by libxml2
>  in its own xmlNode structure.  You can't add methods to it like you
>  could if you wrote your own Node.
>  
>  You could copy the libxml2 tree into your own structure but then you are
>  on your own when it comes to higher level things like xpath and xslt.

I imagined that you would write forwarding functions for the underlying API,
so when you are given an Xpath query, you pass it on to the underlying API and
then wrap the result.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thread:
Stefan Seefeld
Anthony Williams
Hamish Mackenzie
Stefan Seefeld
Anthony Williams
Hamish Mackenzie
Bohdan
Stefan Seefeld
Hamish Mackenzie
Stefan Seefeld
Hamish Mackenzie
Hamish Mackenzie
Stefan Seefeld
Hamish Mackenzie
Stefan Seefeld
Hamish Mackenzie
Stefan Seefeld
Hamish Mackenzie
Bohdan
Stefan Seefeld
Stefan Seefeld
Hamish Mackenzie
Stefan Seefeld
Hamish Mackenzie
Hamish Mackenzie

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved