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
Add void* user data to xml_node_struct #76
Comments
Why would you need user data on a pugixml node!? Please provide a minimal code example! |
Because I want associate it with a handle_less window : ) |
In short, I wish it is not only a xml parser, but also a tree manager ! |
Note that you can use separate lookup tables (e.g. std::map<xml_node, T> or std::unordered_map<xml_node_struct*, T> - you can get the pointer to xml_node_struct using internal_object() method) to solve this without changing pugixml. The problem with adding this is memory cost. This increases the DOM size by ~12% in the default mode; in compact mode this would either increase the node size ~2x for some platforms (e.g. on x64 it'd go from 12 bytes to 24 because of alignment), or would be implemented as a separate lookup table so you might as well do it yourself externally. |
With "map" solution, compared to the increase of a user data "void* ", the overall memory consumption, time consumption will be greater. Of course, when you don't use the "user data", the memory is wasted. |
In my opinion, as long as this feature is needed by only small number of people (only 1 so far) you have to go with std::map solution. Because otherwise, huge amount of people who does not need this feature (all other people so far) will waste 12% of memory just for the sake of one man convenience. |
Notice that you could as well add a configuration to xml_document to set how much extra bytes to allocate per node, which if by default is set to zero then will not cost anything for those who don't use this feature. Yet I'm not convinced this a useful feature. User data pointers are used mostly for associating callbacks with concrete user instances, but here we don't have callbacks originating from pugixml, so its usage is somewhat moot. |
Additionally, my experience has been that when you do want to attach metadata to xml_nodes, you generally only want a partial subset to have one, or you want different subsets to have different metadata - I usually use map or unordered_map for this and it works reasonably well (of course it's space inefficient, which could be solved with a better hash map implementation). Anyway, I'm closing this for now since there does not seem to be an awful lot of demand. If it does reappear my inclination is to add an extra define to keep the code simpler (at the expense of an extra amount of configurations - which in this case would be probably left untested). |
Incidentally, just found the need for a "user data" field of sort in the xml node. In my case, a simple boolean would be enough, as I just need to flag the node. I could do it by adding an attribute to it, or keeping a separate unordered_map, but those would waste more memory and CPU than having a boolean flag embedded in the node itself. |
One more vote for this feature :) . I've been looking, and there doesn't seem to be consensus around a single generic tree-with-named-nodes library supporting C++11. Adding a userdata option would permit pugixml to fill this niche. Thanks for considering this request! |
@cxw42 check this generic |
@igagis Nice --- thanks very much for the pointer! I hadn't seen that project. |
like this:
and add 2 function mebers to xml_node like this
english is pool , be sorry : (
The text was updated successfully, but these errors were encountered: