[LLVMdev] [cfe-dev] C++11 reverse iterators (was C++11 is here)
Sean Silva
silvas at purdue.edu
Tue Mar 4 15:38:28 PST 2014
On Tue, Mar 4, 2014 at 6:11 PM, Chris Lattner <sabre at nondot.org> wrote:
>
> On Mar 4, 2014, at 2:51 PM, Sean Silva <silvas at purdue.edu> wrote:
>
>
>
>
> On Mon, Mar 3, 2014 at 12:26 AM, 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.
>>
>
> `enumerate` is going to be so much more annoying to use without tuple
> unpacking in the `for` syntax :(
>
>
> Sure, it won't be as nice as Python, but in my limited experience with
> C++'11 foreach loops, the #1 reason I can't use them is because there is no
> way to parallel iterate two vectors (as a random example) which would be
> simple if an index were available. It doesn't matter to me how
> syntactically convenient it is to get the index, so long as it is possible.
>
Sure. It definitely won't be unbearable. Iterating two vectors in parallel
also suggests a variadic `auto zip(...) -> std::tuple<...>` helper.
-- Sean Silva
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/ab21d909/attachment.html>
More information about the llvm-dev
mailing list