View mode: basic / threaded / horizontal-split · Log in · Help
July 04, 2012
Re: Proposal: takeFront and takeBack
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 ?
July 04, 2012
Re: Proposal: takeFront and takeBack
> 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?
July 04, 2012
Re: Proposal: takeFront and takeBack
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
July 04, 2012
Re: Proposal: takeFront and takeBack
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.
July 04, 2012
Re: Proposal: takeFront and takeBack
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
July 04, 2012
Re: Proposal: takeFront and takeBack
> 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.
July 04, 2012
Re: Proposal: takeFront and takeBack
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
July 04, 2012
Re: Proposal: takeFront and takeBack
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.
July 04, 2012
Re: Proposal: takeFront and takeBack
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.
July 04, 2012
Re: Proposal: takeFront and takeBack
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); }
}
1 2 3 4
Top | Discussion index | About this forum | D home