[LLVMdev] Best method for filtering LLVM container types?

Talin viridia at gmail.com
Mon Jul 11 14:18:07 PDT 2011


On Mon, Jul 11, 2011 at 10:59 AM, Andrew Trick <atrick at apple.com> wrote:

> On Jul 9, 2011, at 11:30 AM, Talin wrote:
> > I'm using the various LLVM set containers (SmallPtrSet and the like), and
> something I need to do fairly often is iterate over a set, removing all
> elements that don't pass a test. Now, doing this on lists is fairly
> straightforward using the "it = container.erase(it)" idiom so as to keep the
> iterator valid during the delete. However, the set classes don't have a
> means to both iterate and mutate the set at the same time. This means that I
> tend to use SmallVector in a lot of places where I really want to use a set.
> In other cases I copy from one set to another as I'm filtering, although I'm
> concerned about the overhead of copying the set.
> >
> > What I'm wondering is what's the best practice for these kinds of
> operations?
>
>
> I'm not sure if LLVM has a preferred idiom, although I'm sure copying
> elements is fine in most cases.
>
> Ideally, SmallSet iterators would work just like std::set iterators so the
> containers would be interchangeable. But I don't see an easy way to
> implement those semantics. Unless I'm missing something, it seems fairly
> easy to implement it = container.erase(it) in SmallSet with some care to
> check for underlying container switches, I'm just not sure what to call it,
> erase_advance? Alternatively, SmallSet could have an "erase_if" member
> function.
>
> Actually that reminds me of another question I've been wondering about -
how would llvm-devs feel about patches to implement more of the standard STL
container methods on the various ADT container types? Would that be
considered unnecessary bloating of the code? (Part of my general "if
something obvious isn't there, then it isn't there for a reason" paranoia.)


> -Andy
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110711/4f2d5a41/attachment.html>


More information about the llvm-dev mailing list