On Thu, 2015-04-16 at 15:52 +0200, Petr Machata wrote: > Mark Wielaard <[email protected]> writes: > > > Is that a common use case? I would have imagined that you would iterate > > over just the Dwarf_Dies of one particular unit separately or given a > > That would be along these lines: > > for (die_tree_iterator it (uit), end (++uit); it != end; ++it) > ;
O, that is pretty nice. I hadn't thought of that. > > particular Dwarf_Die would like it to iterate over just the die_tree > > under that DIE. Given the current design of the die_tree_iterator how > > would one do that? > > This is not implemented, though I admit it would be a useful feature. > At this point however I would very much like to keep the scope of the > patch as it is now. My problem is that I am not yet so fluent in my C++ thinking to know whether that would fit the current design or that it would need a completely different class and implementation. I would very much like to avoid adding code that we then have to maintain but that we cannot easily extend to similar use cases and end up with lots of interfaces and implementations. But given the nice idea above of defining a "next iterator as end" for another. Would adding that functionality just be introducing a new constructor that takes a Dwarf_Die and a next_sibling () method that returns an iterator that one can use as above in a for loop to test whether one has walked a subtree? The only disadvantage of that seems to be that it would immediately introduce a v2 variant if we do it after a public release. > > Also I think that we really should provide an easy way to walk the > > logical DIE tree. Which means resolving DW_TAG_imported_unit DIEs and > > just continue with the children of the imported unit at that point. > > There should of course also be an option to walk the "raw" DIE tree. But > > it feels wrong to let the user do logical walks on their own, checking > > for imported_unit tags, walking the imported_unit children tree, keep > > their own parent stack, etc. > > I agree, this would be tremendously useful--we discussed this recently > on this list after all. But it should be implemented in C libdw, and > only then (optionally) reused in the C++ wrappers. I was thinking just doing it on the C++ level. But yes, it would be nice to also have that on the C level libdw interface. That was this discussion where you came up with a pretty nice plan: https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-October/004204.html Again my worry is about whether retrofitting such a design into the current class is possible or not. Would it be as simple as adding a new constructor, a boolean field and using the new C functions (and updating the version) or would we need a whole new class/interface for it? So my only worry about just adding this code as is now, is that I don't have a good feeling for how to evolve this C++ code without creating an unmaintainable mess or abandoning the current code/design. If you could handwave a plausible path forward to add these things then I would agree with adding the code as is. Thanks, Mark
