[LLVMdev] [cfe-dev] C++11 reverse iterators (was C++11 is here)

Sean Silva silvas at purdue.edu
Tue Mar 4 14:55:15 PST 2014


On Mon, Mar 3, 2014 at 3:01 AM, Chris Lattner <sabre at nondot.org> wrote:

> On Mar 2, 2014, at 10:47 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> I'm not aware of the prior art or standards are here, but I think that a
>>>> global reverse() adapter is the way to go.  Likewise, we should have a
>>>> standard "enumerate()" adaptor like python.
>>>
>>>
>>> I definitely prefer the global adaptor pattern.  As for prior art, I had
>>> played with it a bit, and came up with
>>> https://gist.github.com/compnerd/5694186 a while back.
>>>
>>
>> Yea, there is a pretty strong move toward range adaptors. If possible,
>> I'm going to work on contributing a basic selection of them to LLVM's ADT
>> specifically to address the immediate needs of range-based for loops.
>>
>>
>> Sounds good.  We also have to decide what to do with
>> Function::arg_begin() for example (and all the other secondary ranges
>> hanging off IR and other things).  IMO, "for (auto &arg :
>> F.getArguments())" makes the most sense.
>>
>
> I was actually going to check in this, but I can post it for review if
> folks are worried.
>
> My plan was to provide an implementation of std::iterator_range<T> and
> then provide 'F.arguments()' which returns it.
>
>
> Nice.  What's the logic behind .arguments() vs .getArguments()?  I don't
> have a strong opinion either way, but there should be rationale.
>

My 2c is that we should choose a naming convention that yields a completely
consistent way to mechanically transform foo_begin/foo_end to the range
equivalent. Even just the plural has the usual natural language exceptions.
My vote is for foo_begin/foo_end/foo_range.

-- Sean Silva


>
> -Chris
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/e7faef69/attachment.html>


More information about the llvm-dev mailing list