On Tue, 09 Apr 2013 19:31:59 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Tue, Apr 09, 2013 at 07:18:25PM -0400, Steven Schveighoffer wrote:
>> On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling
>> <joseph.wakeling@webdrake.net> wrote:
>>
>> >On 04/10/2013 12:50 AM, Joseph Rushton Wakeling wrote:
>> >>I did consider something like that.
>> >
>> >By the way: the reason that I rejected the temporary-variable choice
>> >was that I couldn't really see the difference cost-wise between doing
>> >that, versus returning var.dup from front().  Especially as it's not
>> >necessarily guaranteed that front will be called frequently (I might
>> >just popFront() until the range is empty and then take the final
>> >front value).
>>
>> Calling front after empty is not good range policy, once empty,
>> front is possibly invalid or points at invalid memory.
> [...]
>
> I believe it was proposed that .front should assert if .empty returns
> true. Personally I think that's a bit too extreme, but nevertheleses, I
> agree that calling .front after .empty returns true is sloppy coding,
> and can easily lead to bugs or runtime errors.

That is not necessary.  A range does not just have to be a range, it just has to support a range interface.

It can be perfectly valid for front to not assert.  It can be also valid for it to assert.  It just means that functions that generically operate on ranges cannot count on front working after empty is true (and that WOULD be a bug).

For example, if the OP replaced his range with someone else's, he may run into that situation.  But as long as he is the author, it is not illegal for an object that is also a range to be empty and have front still work.

-Steve

On Tue, Apr 09, 2013 at 09:59:42PM -0400, Steven Schveighoffer wrote:
> On Tue, 09 Apr 2013 19:31:59 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> 
> >On Tue, Apr 09, 2013 at 07:18:25PM -0400, Steven Schveighoffer wrote:
> >>On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> >>
> >>>On 04/10/2013 12:50 AM, Joseph Rushton Wakeling wrote:
> >>>>I did consider something like that.
> >>>
> >>>By the way: the reason that I rejected the temporary-variable choice was that I couldn't really see the difference cost-wise between doing that, versus returning var.dup from front(). Especially as it's not necessarily guaranteed that front will be called frequently (I might just popFront() until the range is empty and then take the final front value).
> >>
> >>Calling front after empty is not good range policy, once empty, front is possibly invalid or points at invalid memory.
> >[...]
> >
> >I believe it was proposed that .front should assert if .empty returns true. Personally I think that's a bit too extreme, but nevertheleses, I agree that calling .front after .empty returns true is sloppy coding, and can easily lead to bugs or runtime errors.
> 
> That is not necessary.  A range does not just have to be a range, it just has to support a range interface.
> 
> It can be perfectly valid for front to not assert.  It can be also valid for it to assert.  It just means that functions that generically operate on ranges cannot count on front working after empty is true (and that WOULD be a bug).
[...]

Yes, that was my point. I didn't mean to say that front *should* assert, just that it *might* for some ranges. (In fact, I've written my own ranges that do support calling .front even when .empty is true.) In generic code, though, one should not assume one way or another.


T

-- 
Study gravitation, it's a field with a lot of potential.

On Tuesday, 9 April 2013 at 23:18:26 UTC, Steven Schveighoffer wrote:
> On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
>> By the way: the reason that I rejected the temporary-variable choice was that I
>> couldn't really see the difference cost-wise between doing that, versus
>> returning var.dup from front().  Especially as it's not necessarily guaranteed
>> that front will be called frequently (I might just popFront() until the range is
>> empty and then take the final front value).
>
> Calling front after empty is not good range policy, once empty, front is possibly invalid or points at invalid memory.
>
> -Steve

I'm pretty sure he realizes this, his original code shows how he is doing this. He expects 'output' to hold the final front value, but instead it holds the empty "value."

Joseph, I think you will have to profile to decide which is the fastest for your use case.

On 04/10/2013 08:22 PM, Jesse Phillips wrote:
> I'm pretty sure he realizes this, his original code shows how he is doing this. He expects 'output' to hold the final front value, but instead it holds the empty "value."
> 
> Joseph, I think you will have to profile to decide which is the fastest for your use case.

Agree.  I do also see the risks in these assumptions with respect to front -- they can be safely worked around within my code but it's not a very friendly construction to put in front of other people.

On 04/10/2013 01:18 AM, Steven Schveighoffer wrote:
> Calling front after empty is not good range policy, once empty, front is possibly invalid or points at invalid memory.

It's not necessarily required to actually call front with the range empty: one could do something like,

	for(; !sim.empty; sim.popFront())
		v = sim.front;

... and the way that popFront() operates means that, while the output of front()
may be transient in general, the last value will remain.

Though I agree that, even in this case, it's is a potentially problematic situation (there's something weird about the idea of a range that is transient except for the last entry).  I will have to profile with .dup enabled and see what changes.