[PATCH] Add FilteredArgList to represent filtered arglist

[Michael Spencer]

On Tue, May 28, 2013 at 11:47 AM, Rui Ueyama <ruiu at google.com> wrote:

> 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
>

It's still quite heavily C++11 code. It needs to be converted to C++03 to
go into ADT. There was also concern about this being the right API for
LLVM. I added it to lld knowing that it may need to change.

- Michael Spencer


>
>
>
> 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/20130530/7e799ae4/attachment.html>