<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 10:57 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
On Mar 19, 2014, at 11:32 AM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br>
<br>
> On Wed, Mar 19, 2014 at 2:13 PM, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br>
>> Hi all,<br>
>><br>
>> As RFCs go this is short and sweet - I think it would be nice to add an<br>
>> empty method to iterator_range. Something like:<br>
>><br>
>> bool empty() const { return begin() != end(); }<br>
>><br>
>> My motivation is to make the 'if' test at the start of this common pattern<br>
>> tidier:<br>
>><br>
>> if (!collection.empty())<br>
>>  // initialization...<br>
>> for (auto& c : collection)<br>
>>  // do something for each c.<br>
>><br>
>> which I think that is preferable to:<br>
>><br>
>> if (collection.begin() != collection.end())<br>
>>  // initialization...<br>
>> // for each...<br>
>><br>
>> The empty method is just a single iterator comparison, so it should be valid<br>
>> and cheap for any underlying iterator type.<br>
>><br>
>> Pros:<br>
>> - Enables small aesthetic improvements.<br>
>> - Would make iterator_range look slightly more "container-like", so it could<br>
>> substitute into more template code, though I'd expect templates that take<br>
>> read-only containers rather than iterators to be very rare in C++, and<br>
>> templates that take collections and use only begin, end and empty to be<br>
>> rarer still.<br>
>><br>
>> Cons: ?<br>
<br>
</div></div>I’m in favour.<br></blockquote><div><br></div><div>+1. I also ran into this pattern, and suggested to add empty() method in r203354 review thread.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><br>
> This is a pattern I ran into a handful of times when range-ifying<br>
> parts of clang (but not so frequently that I felt it was a major win),<br>
> so I'm roughly in favor of the API. However, if there's been<br>
> standardization efforts for range, we should be sure that we're doing<br>
> something compatible there.<br>
<br>
</div>There are a couple of proposals [1][2] that I can find.  It sounds like the<br>
exact set of methods to provide is somewhat contentious [3].  empty() seems<br>
pretty innocuous though.  Note that the standard proposals use std::range<br>
instead of std::iterator_range.<br>
<br>
In my opinion, other methods (e.g., front(), back(), and (for random access<br>
iterators) operator[]) would also be useful.<br>
<br>
[1]: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html</a><br>
[2]: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html</a><br>
[3]: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3513.html#range-arg" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3513.html#range-arg</a><br>
<div class=""><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>