Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better node visitor interface #103

Open
zeux opened this issue Jul 16, 2016 · 1 comment
Open

Better node visitor interface #103

zeux opened this issue Jul 16, 2016 · 1 comment

Comments

@zeux
Copy link
Owner

zeux commented Jul 16, 2016

Assuming node visitor interface is a good idea (is it? not 100% clear), there are several problems with existing xml_tree_walker:

  1. ::begin/::end are pretty pointless - could be called from external code
  2. No way to get callbacks before/after the subtree - this is what begin/end could have been. This was mentioned (if memory serves) in https://code.google.com/p/pugixml/issues/detail?id=219 but this link is now dead.
  3. No way to skip a subtree. This is mentioned in issue wish to add another xml_node::traverse function meber #77.

While manually implementing a recursive traversal is pretty trivial, all traversals that pugixml implements are stackless (which is not as simple/concise to write yourself), so there seems to be some value in a generic traversal. There are still several implementation options though:

  1. Interface with virtual functions. This will have to be a new interface to maintain binary compatibility - xml_tree_visitor or something like that.
  2. Pseudo-interface with templated member functions. This can be faster, although in a non-LTO build it's a weird tradeoff - templated implementations can't inline node structure accessors, while an implementation based on virtual dispatch can't inline user code. With LTO or header-only mode the approach based on compile-time polymorphism should be faster though. This can be seen as an extension of xml_node::find_node.
  3. Tree iterator with ability to descend into a subtree or skip it, so that the user code is in control of the flow.

These need to be evaluated for the performance and versatility in various scenarios. 1 and 2 are extensions of existring ::traverse() support while 3 is basically a separate idea.

Finally, there is - as it is - quite a few ways to traverse the nodes in pugixml. Ideally if we do need a new way it has to supplant the old one - that is, we should at the minimum deprecate existing ::traverse in favor of whatever the new interface is.

@jamsilva
Copy link

I believe this is a useful feature and I have a custom implementation of options 1+3 at https://github.com/jamsilva/pugixml_tree_visitor. Feel free to use, change and distribute it under the same license as pugixml.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants