On Thursday, July 05, 2012 00:03:02 Timon Gehr wrote: > 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); } > }
Not to mention, in many cases, you _can't_ return a ref like deadalnix suggests, because that would require that front be returning an lvalue, and it often isn't. And in the case of strings - which is the prime reason for this discussion in the first place - it definitely can't return an lvalue, because front is calculated (that and returning a value from popFront would make popFront much more expensive in the case where you _don't_ actually need to access front, so making popFront return an element doesn't help the string case at all). - Jonathan M Davis