From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0347481305640816397==" MIME-Version: 1.0 From: Petr Machata To: elfutils-devel@lists.fedorahosted.org Subject: Re: [PATCH 2/2] Add C++ iterators Date: Thu, 16 Apr 2015 17:42:49 +0200 Message-ID: <87a8y8m64m.fsf@redhat.com> In-Reply-To: 1429196768.31971.76.camel@bordewijk.wildebeest.org --===============0347481305640816397== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Mark Wielaard writes: > 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? Yes, that's how I'd do it. > The only disadvantage of that seems to be that it would immediately > introduce a v2 variant if we do it after a public release. I don't even think it would. Adding a new constructor doesn't break any existing clients. API-wise it would be stable as well, this adds use cases, doesn't change any (not even by way of implicit conversions from, say, Dwarf_Die * to unit_iterator). As long as your iteration is limited to well-formed sub-tree (i.e. you don't wan't to e.g. start at one leaf node and progress through half the CU to another leaf node), the simple vector of offsets would, I think, be still enough to keep all the context that you need. There might be code that assumes that iteration starts and ends at CU DIE's, but that could be transparently fixed. > 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/0042= 04.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? I'm not sure. I don't think so, at least you would need a different way of keeping track of context. Personally I think adding a new iterator that builds on the raw one is the best option. That would mean that you couldn't pass a logical iterator to a function that expects a raw one. But you can't likewise pass, say, a child iterator to such function--the genericity is just not there. This sort of thing would have to be achieved by making the function template. One could also make the new iterator configurable, like Frank says in his mail. Then you would have a single tree iterator type that can behave either way. I still think exposing raw iterator is the right way forward, because it is a logical building block. A logical tree iterator can be built on top of that even without C support, if that's what's deemed best. Thanks, Petr --===============0347481305640816397==--