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

On Mar 2, 2014, at 10:27 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Sun, Mar 2, 2014 at 10:13 PM, Saleem Abdulrasool <compnerd at
compnerd.org> wrote:
> On Sun, Mar 2, 2014 at 9:26 PM, Chris Lattner <sabre at nondot.org>
wrote:
> 
> On Mar 2, 2014, at 8:53 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> 
> > On 3 March 2014 12:32, Pete Cooper <peter_cooper at apple.com>
wrote:
> >> Would those work with a foreach construct? Perhaps I forgot to
mention that was what I'm trying to work out here.
> >>
> >> In example 3 I was wondering if we could define a method
reverse(). We could use sfinae to wrap that around rbegin/rend if people like
that style?
> >
> > Sorry, I was too terse... ;)
> >
> > If MF is a reverse_iterator, it'd just work, no? But to get the
> > reverse iterator, I think reverse() would be the best general pattern,
> > since you can adapt it to each container needs.
> 
> 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.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140302/cd9fb4ce/attachment.html>

On Sun, Mar 2, 2014 at 10:41 PM, Chris Lattner <sabre at nondot.org>
wrote:
>
> On Mar 2, 2014, at 10:27 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
>
>
> On Sun, Mar 2, 2014 at 10:13 PM, Saleem Abdulrasool <compnerd at
compnerd.org
> > wrote:
>
>> On Sun, Mar 2, 2014 at 9:26 PM, Chris Lattner <sabre at
nondot.org> wrote:
>>
>>>
>>> On Mar 2, 2014, at 8:53 PM, Renato Golin <renato.golin at
linaro.org>
>>> wrote:
>>>
>>> > On 3 March 2014 12:32, Pete Cooper <peter_cooper at
apple.com> wrote:
>>> >> Would those work with a foreach construct? Perhaps I
forgot to
>>> mention that was what I'm trying to work out here.
>>> >>
>>> >> In example 3 I was wondering if we could define a method
reverse().
>>> We could use sfinae to wrap that around rbegin/rend if people like
that
>>> style?
>>> >
>>> > Sorry, I was too terse... ;)
>>> >
>>> > If MF is a reverse_iterator, it'd just work, no? But to
get the
>>> > reverse iterator, I think reverse() would be the best general
pattern,
>>> > since you can adapt it to each container needs.
>>>
>>> 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.

>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140302/dc1fbb3f/attachment.html>

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.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140303/fabd5499/attachment.html>