Le 03/07/2012 19:27, monarch_dodra a écrit :
> On Tuesday, 3 July 2012 at 17:22:17 UTC, Wouter Verhelst wrote:
>> Jonathan M Davis <jmdavisProg@gmx.com> writes:
>>
>> Couldn't you just overload popFront?
>>
>> have a void popFront which throws off the first element without
>> returning anything, and an auto popFront which does return data.
>>
>> I'd always been taught that "pop" means "read a bit and chop it off",
>> which means that having to first read the front and then pop it off
>> (i.e., in two separate methods) feels rather counterintuitive to
>> me. That's in addition to the fact that yes, there's a performance
>> issue.
>>
>> But hey, I've only been doing this D thing for a few weeks, so feel free
>> to ignore me if I'm not making any sense :-)
>
> You can't overload by return value, so that is not possible.
>
> As far as I can recall, I've always been taught that pop does NOT
> (should not) return a value. Rationale being it makes you pay for a
> read/copy you may not have asked for. That's the way C++ does it, and is
> what I've come to expect from any language.

Many languages does this (it doesn't mean it is the right thing to do). Do you know why this shouldn't be done ?

> Many languages does this (it doesn't mean it is the right thing to do). Do you know why this shouldn't be done ?

In C++ it was exception safety, wasn't it?

On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
> > Many languages does this (it doesn't mean it is the right thing to do). Do you know why this shouldn't be done ?
> 
> In C++ it was exception safety, wasn't it?

I believe that it was purely a question of speed. If popFront returns an element, then that element gets copied, and if you didn't need to access the element, then that's wasted cycles. You have to worry about exceptions in either case, depending on the what popFront is doing.

- Jonathan M Davis

On Wednesday, 4 July 2012 at 18:40:50 UTC, Jonathan M Davis wrote:
> On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
>> > Many languages does this (it doesn't mean it is the right thing
>> > to do). Do you know why this shouldn't be done ?
>> 
>> In C++ it was exception safety, wasn't it?
>
> I believe that it was purely a question of speed. If popFront returns an
> element, then that element gets copied, and if you didn't need to access the
> element, then that's wasted cycles. You have to worry about exceptions in
> either case, depending on the what popFront is doing.
>
> - Jonathan M Davis

If you pop from a container and return this the copy constructor / postblit will run. If in this moment a exception is thrown, than this value is lost.

On Wednesday, July 04, 2012 22:10:36 Tobias Pankrath wrote:
> On Wednesday, 4 July 2012 at 18:40:50 UTC, Jonathan M Davis wrote:
> > On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
> >> > Many languages does this (it doesn't mean it is the right
> >> > thing
> >> > to do). Do you know why this shouldn't be done ?
> >> 
> >> In C++ it was exception safety, wasn't it?
> > 
> > I believe that it was purely a question of speed. If popFront
> > returns an
> > element, then that element gets copied, and if you didn't need
> > to access the
> > element, then that's wasted cycles. You have to worry about
> > exceptions in
> > either case, depending on the what popFront is doing.
> > 
> > - Jonathan M Davis
> 
> If you pop from a container and return this the copy constructor / postblit will run. If in this moment a exception is thrown, than this value is lost.

Yes. But the cost of copying the value and the cost of the exception are separate. Simply popping off the element could throw an exception (in the case of strings in D, you'll get a UTFException if the string is malformed). So, _regardless_ of whether you return an element, you potentially risk an exception being thrown (depending on the implementation of the container or range). And so I think that exceptions are pretty much irrelevant to the discussion of whether returning an element from popFront is a good idea or not.

- Jonathan M Davis

> Yes. But the cost of copying the value and the cost of the exception are
> separate.
The argument is not about performance, it's about loosing values.

> Simply popping off the element could throw an exception (in the case
> of strings in D, you'll get a UTFException if the string is malformed). So,
> _regardless_ of whether you return an element, you potentially risk an
> exception being thrown (depending on the implementation of the container or
> range).
It's not the same.

> And so I think that exceptions are pretty much irrelevant to the
> discussion of whether returning an element from popFront is a good idea or
> not.

How would you implement an returning popFront for a generic container that
does not leak values? It's not possible (at least in C++, not sure in D), so it is relevant. Maybe it was not the prime reason, but it is a good reason non the less.

On Wednesday, July 04, 2012 22:34:46 Tobias Pankrath wrote:
> > Yes. But the cost of copying the value and the cost of the
> > exception are
> > separate.
> 
> The argument is not about performance, it's about loosing values.
> 
> > Simply popping off the element could throw an exception (in the
> > case
> > of strings in D, you'll get a UTFException if the string is
> > malformed). So,
> > _regardless_ of whether you return an element, you potentially
> > risk an
> > exception being thrown (depending on the implementation of the
> > container or
> > range).
> 
> It's not the same.
> 
> > And so I think that exceptions are pretty much irrelevant to the
> > discussion of whether returning an element from popFront is a
> > good idea or
> > not.
> 
> How would you implement an returning popFront for a generic
> container that
> does not leak values? It's not possible (at least in C++, not
> sure in D), so it is relevant. Maybe it was not the prime reason,
> but it is a good reason non the less.

Okay. I see what you mean now. I thought that the idea was that you would somehow avoid exceptions when popping such that the fact returning the element could generate an exception made it then possible to have exceptions be thrown from popFront, which would be a problem.

Well, in most cases, I honestly don't think that that would be a problem, since if an exception is thrown from the copy constructor / postblit of the object being returned, it's probably foobared anyway, and having it on the front of the range (or container) would really buy you anything. And if you didn't actually want the element, then it doesn't really matter anyway - beyond the fact that you now have an extra way to have an exception be thrown. But it is true that you avoid that whole issue if you separate returning the element from popping it. Regardless, performance alone makes it worthwhile to not have popFront return anything IMHO, and that's the argument that I've always heard.

- Jonathan M Davis

Le 04/07/2012 20:40, Jonathan M Davis a écrit :
> On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
>>> Many languages does this (it doesn't mean it is the right thing
>>> to do). Do you know why this shouldn't be done ?
>>
>> In C++ it was exception safety, wasn't it?
>
> I believe that it was purely a question of speed. If popFront returns an
> element, then that element gets copied, and if you didn't need to access the
> element, then that's wasted cycles. You have to worry about exceptions in
> either case, depending on the what popFront is doing.
>
> - Jonathan M Davis

If you return by reference, you get an overhead of 1 MOV instruction. This is ridiculous.

You win nothing else, because the register things are returned in is a trash register, so you have the returned thing, or garbage in it, you can assume nothing else.

The cost is neglectible. And any compiler is able to reduce that cost to 0 when inlining if the value is not read. If the compiler don't inline, an extra MOV instruction is not will slow you down.

Le 04/07/2012 22:34, Tobias Pankrath a écrit :
>
>> Yes. But the cost of copying the value and the cost of the exception are
>> separate.
> The argument is not about performance, it's about loosing values.
>

If you implement popFront as
{
	popFront();	// current popFront
	return front;
}

Then no value is lost with Exception. If an Exception is thrown, this is dubious anyway, because the value is likely to be irrelevant anyway.

On 07/04/2012 11:53 PM, deadalnix wrote:
> Le 04/07/2012 20:40, Jonathan M Davis a écrit :
>> On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
>>>> Many languages does this (it doesn't mean it is the right thing
>>>> to do). Do you know why this shouldn't be done ?
>>>
>>> In C++ it was exception safety, wasn't it?
>>
>> I believe that it was purely a question of speed. If popFront returns an
>> element, then that element gets copied, and if you didn't need to
>> access the
>> element, then that's wasted cycles. You have to worry about exceptions in
>> either case, depending on the what popFront is doing.
>>
>> - Jonathan M Davis
>
> If you return by reference, you get an overhead of 1 MOV instruction.
> This is ridiculous.
>

You get an 'overhead' of calling front, which is potentially unbounded.

struct Map(...){
    ...
    @property auto ref front() { return f(otherRange.front); }
}