<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 9:41 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 08/24/2015 01:21 PM, Kinkie wrote:<br>
<span class=""><br>
> On Mon, Aug 24, 2015 at 8:37 PM, Alex Rousskov wrote:<br>
><br>
>     On 08/24/2015 12:08 PM, Amos Jeffries wrote:<br>
>     > On 25/08/2015 4:49 a.m., Kinkie wrote:<br>
><br>
>     > + * behavior is undefined if the iterator<br>
>     > + * is incremented (or decremented) outside the range representing<br>
>     valid<br>
>     > + * enum symbols<br>
><br>
>     I hope that behavior is well defined: For many enums/iterators,<br>
>     iterators are "incremented outside the range representing valid enum<br>
>     symbols" to reach end() and rend(). I asked you about these beyond-range<br>
>     increments, and you assured me that they work fine. We should not add a<br>
>     comment saying otherwise.<br>
><br>
><br>
> I may have difficulty expressing myself here. The iterators work just<br>
> fine outside the range. Dereferencing them is another matter, as there<br>
> is no valid symbol to cast them to.<br>
<br>
</span>Remove that paragraph then. It is a Bad Idea to try to document how<br>
iterators work in general when describing a specific class. Incrementing<br>
or dereferencing end() or equivalent is not going to work well, but we<br>
should not document that.<br></blockquote><div><br></div><div>How about:<br> * The iterator does not check for bounds when incrementing or decrementing,<br> * that responsibility is left to the caller<br>?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
>     >> + *   zeroth, first, second, onePastLast, fourth<br>
><br>
><br>
>     Please make onePastLast last.<br>
<br>
<br>
</span><span class="">> I'm trying to highlight the fact that<br>
> the dereferencing will only happen on EnumType::first and<br>
> EnumType::second. Any suggestion on how to clearly express it is welcome.<br>
<br>
</span>1. Replace the current enum values with five color names: white, blue,<br>
red, orange, pink.<br>
<br>
2. Iterate from blue to orange.<br>
<br>
3. Add a do_stuff(v) call comment saying that it will be called with red<br>
and blue values only.<br></blockquote><div><br></div><div>Done<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For extra points, order colors by hue :-).<br></blockquote><div><br></div><div>Dammit Jim, I'm an engineer, not a painter! :P<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
>     You might want to add a comment that EnumRange() cannot be used to<br>
>     iterate whole enums without [end] markers and, hence, all enums that<br>
>     require iteration of the entire range must have markers.<br>
<br>
<br>
> I'm trying to detail that in the documentation for EnumRangeT. Not<br>
> clearly enough, I guess.<br>
<br>
<br>
</span>My bad. Sorry I missed that paragraph. It is OK. I would remove the<br>
"Otherwise you will have to ..." suggestion though -- no need to<br>
instruct folks to write bad code.<br></blockquote><div><br></div><div>Ok.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Note that one _can_ use EnumRange() to iterate whole enums; they just<br>
need a marker to do that. You do not have to polish your comment though.<br></blockquote><div><br></div><div>That'd be quite redundant, it's stated well enough already that the last element in the range is not going to be involved in the loop.<br></div><div>Thanks, and sorry for missing your comments earlier on. Updated patch will follow after I address Amos' comments as well.<br></div><div> </div></div>  Francesco<br></div></div>