<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Lang and others,<div class=""><br class=""></div><div class="">This iterator basically requires another indirection to get to the underlying Child. So you get a compile error when trying to use the iterator as it is an <ErrorOr>. So the example really is to change something like this (as the diff in ELF/InputFiles.cpp):</div><div class=""><br class=""></div><div class="">for (const Archive::Child &Child : File->children()) {</div><div class=""> …</div><div class=""><br class=""></div><div class="">to this:</div><div class=""><br class=""></div><div class=""> for (auto &ChildOrErr : File->children()) {<br class=""> error(ChildOrErr, "Could not get the child of the archive " +<br class=""> File->getFileName());<br class=""> const Archive::Child Child(*ChildOrErr);</div><div class=""> ...</div><div class=""><br class=""></div><div class="">Which seems a bit cleaner than testing the result of child_begin() before the for loop and checking getNext() even if it can be wrapped in some case in and Increment() routine.</div><div class=""><br class=""></div><div class="">My thoughts,</div><div class="">Kev</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Oct 29, 2015, at 7:50 PM, Lang Hames via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Yep. The standard C++ iterator concept doesn't apply here, since it doesn't deal with failure, and checking on deref rather than increment means you can accidentally do multiple increments without checking. My intent was to have increment crash if you run it on an error'd out iterator, but that's not as good as a compile-time check. I think it's a matter of personal taste whether the cost (IMHO fairly minimal, since in practice you almost always deref after increment) is worth paying for the gain (also arguably minimal) of a neater iteration idiom.<div class=""><div class=""><br class=""></div><div class="">I don't have particularly strong feelings either way.</div><div class=""><br class=""></div><div class="">- Lang.</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Oct 29, 2015 at 5:51 PM, David Blaikie <span dir="ltr" class=""><<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Thu, Oct 29, 2015 at 5:27 PM, Lang Hames via llvm-commits <span dir="ltr" class=""><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank" class="">llvm-commits@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Hi Rafael,<div class=""><br class=""></div><div class="">How could you ignore the error in Kevin's solution?</div><div class=""><br class=""></div><div class="">I think your solution and his are essentially the same, except that you check the error on increment and he checks it on dereference. In practice you always have to do both operations (you can't do multiple increments without checking the error anyway, and you can just do that by deref'ing), and checking via deref allows you to used range-based for, which makes the code neater.</div></div></blockquote><div class=""><br class=""></div></span><div class="">I'm not taking a position either way - but that does present a difficult problem for the iterator contract, to say that you can't increment it twice without dereferencing... that's not really in the iterator playbook/contract (could implement a little extra support for that by allowing an error-state iterator to be incremented to become the end iterator). I know you've mentioned it before (the "can't increment twice without checking") but it became a bit clearer to me in this recent email exchange to the point that I would be a little less comfortable with it.<br class=""><br class="">I can't find the example you guys had:<br class=""><br class="">for (auto &Thing : things) {<br class=""> if (!Thing)<br class=""> return Thing.getError();<br class=""> ...<br class="">}<br class=""><br class="">& yeah, nothing that comes to mind is as tidy/simple as that, my nearest might be:<br class=""><br class="">auto Iter = things.begin();<br class="">while (auto &Thing = Iter.Next()) {<br class=""> ....<br class="">}<br class="">if (!Iter)<br class=""> return Iter.getError();<br class=""><br class="">(where "Iter" isn't a traditional iterator in any sense - it has ErrorOr<T> Next() and getError (& possibly boolean testability))<br class=""><br class="">The obvious sort of problem I imagine arising from the iterator/range API is something like:<br class=""><br class=""> int count = std::distance(things.begin(), things.end());<br class=""><br class="">Easy to write, and would produce an infinite loop (or crash?) if there was an error during iteration.<br class=""><br class="">- Dave<br class=""><br class="">- Dave</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Lang.</div><div class=""><div class=""><div class=""><br class=""></div><div class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 29, 2015 at 5:11 PM, Rafael Espíndola <span dir="ltr" class=""><<a href="mailto:rafael.espindola@gmail.com" target="_blank" class="">rafael.espindola@gmail.com</a>></span> wrote:<br class=""><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"><span class="">On 28 October 2015 at 15:21, Kevin Enderby <<a href="mailto:enderby@apple.com" target="_blank" class="">enderby@apple.com</a>> wrote:<br class="">
> enderby added a comment.<br class="">
><br class="">
> I agree with Lang and like the original patch where were were handling failure was done inside the iterator. It does allow use of ranged-based for loops and appears to me much cleaner in the code especially in the lld changes needed in <a href="http://reviews.llvm.org/D13990" rel="noreferrer" target="_blank" class="">http://reviews.llvm.org/D13990</a> .<br class="">
<br class="">
</span>I think that the most important consideration is making the error hard<br class="">
to ignore. That means using ErrorOr.<br class="">
<br class="">
The sad reality is that the archive format can cause us to find an<br class="">
error when going from one member to the next. That, with the above<br class="">
requirement means that it doesn't fit on range loop.<br class="">
<span class=""><br class="">
> Rafael, I did "finish it up" based on your t.diff patch and that is below and includes the re-formatting with clang-format-diff, removal of the malformed-archives directory putting the .a files in Inputs and removal of the "nice but independent" changes.<br class="">
><br class="">
> F1026846: llvm_updated_t.diff <<a href="http://reviews.llvm.org/F1026846" rel="noreferrer" target="_blank" class="">http://reviews.llvm.org/F1026846</a>><br class="">
<br class="">
<br class="">
</span>Thanks!<br class="">
<br class="">
You don't need to change ErrorOr.h.<br class="">
<br class="">
The change to detect the end of the archive seems more complicated<br class="">
than necessary (see the attached patch for a suggestion).<br class="">
<br class="">
Cases like the Increment in BinaryHolder expose a naked EC, which is<br class="">
what using ErrorOr is trying to avoid. Just inlining it solves the<br class="">
problem (see patch).<br class="">
<br class="">
Please convert the remaining user of Increment to return void when possible.<br class="">
<br class="">
Cheers,<br class="">
Rafael<br class="">
</blockquote></div><br class=""></div></div></div></div></div>
<br class=""></span><span class="">_______________________________________________<br class="">
llvm-commits mailing list<br class="">
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank" class="">llvm-commits@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br class="">
<br class=""></span></blockquote></div><br class=""></div></div>
</blockquote></div><br class=""></div>
_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits<br class=""></div></blockquote></div><br class=""></div></body></html>