[PATCH] Add FilteredArgList to represent filtered arglist

[Rui Ueyama]

Agreed. We already have a generic range abstraction in lld
(include/lld/Core/range.h) that I want to use for this, and I found that
there was a discussion to move the file out of lld into llvm. Michael, what
is the status of the plan?

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130318/169097.html


On Tue, May 28, 2013 at 11:02 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
>
> On Tue, May 28, 2013 at 10:48 AM, Rui Ueyama <ruiu at google.com> wrote:
>
>> On Mon, May 27, 2013 at 7:35 AM, David Blaikie <dblaikie at gmail.com>wrote:
>>
>>>
>>> On May 26, 2013 12:37 PM, "Rui Ueyama" <ruiu at google.com> wrote:
>>> >
>>> >
>>> >> > +/// FilteredArgList - ArgList with filters. Useful to be used in
>>> >> > +/// range-based for loop to iterate over filtered arguments.
>>> >>
>>> >> Could we just have/use a generic range abstraction (essentially a
>>> simple class template with two iterator members, one returned by begin, the
>>> other by end) rather than writing a custom type here?
>>> >
>>> > What if begin is called twice? Is it okay to return the same object,
>>> not a new one?
>>>
>>> If this is any kind of common iterator it must have the usual/obvious
>>> copy semantics (that's an iterator requirement) - essentially copying the
>>> result of begin should be as good as calling begin twice or there's
>>> something very strange/surprising going on (which isn't unheard of in
>>> llvm's iterators - so feel free to correct/tell me these are weird
>>> iterators that require a special case - I've not looked at them enough to
>>> know either way yet)
>>>
>> No there's no such weird iterator in LLVM as far as I know. I just
>> thought that we might want to avoid the overhead of copying the result of
>> begin, which can be avoided by this patch. Or am I worry too much?
>>
>
> Yeah, certainly worrying too much - iterators generally need to be cheap
> to copy & many algorithms will/should treat them as such. These ones
> certainly are, so far as I can tell - they're just SmallVector iterators,
> which are essentially just plain pointers (or the moral equivalent).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130528/b28055fb/attachment.html>