You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Interface with virtual functions. This will have to be a new interface to maintain binary compatibility - xml_tree_visitor or something like that.
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.
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.
The text was updated successfully, but these errors were encountered:
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.
Assuming node visitor interface is a good idea (is it? not 100% clear), there are several problems with existing xml_tree_walker:
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:
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.
The text was updated successfully, but these errors were encountered: