On Mon, 2011-06-06 at 02:52 -0700, Jonathan M Davis wrote: > On 2011-06-06 02:33, Lars Tandle Kyllingstad wrote: > > Sorry for not following up on this earlier, I got busy with other things > > and completely forgot about it. > > > > On Thu, 2011-05-19 at 18:28 -0400, Robert Jacques wrote: > > > On Thu, 19 May 2011 18:09:09 -0400, Lars Tandle Kyllingstad > > > > > > <[email protected]> wrote: > > > > I can't really see any elegant way to implement save() for such a > > > > range, though, and without save() it doesn't qualify as a forward > > > > range, a bidirectional range or a random-access range -- at least not > > > > as defined by isForwardRange & co. Is there then any point in > > > > implementing the remaining primitives? > > > > > > > > -Lars > > > > > > Well, any routine which uses byRef internally, like I do, won't > > > necessarily care about save, but might use indexing/slicing if available. > > > > > > Besides, what's wrong with something like: > > > > > > static if(/*...*/) > > > ByRef save() > > > { > > > > > > auto ptr = new Range; > > > *ptr = (*_range).save; > > > return byRef(ptr); > > > > > > } > > > > A memory allocation hidden away in a function which is normally very > > cheap. I've somehow gotten the impression that algorithms can use > > save() without worrying about its cost. After all, in most cases it is > > simply implemented as "return this" or similar. If it turns out that > > save() makes no such guarantee, I don't see a problem with the > > implementation you suggest. > > That's one of the main reasons for the debate on whether postblits can/should > be assumed to be cheap. If they are, then algorithms can assume that save is > cheap and be coded accordingly. If they're not, then calling save potentially > becomes something to be avoided whenever possible. But regardless of whether > save can be assumed to be cheap, it _definitely_ has the potential to > allocate > memory. And if something critical to a range is on the heap, then you should > definitely expect a heap allocation in save. > > Unfortunately, I'm not sure where the debate on postblits and cost is. As I > recall, it was pretty much decided that postblits could be assumed to be > cheap, but then issues with COW and reference counting being properly > possible > (due to bugs in the compiler I suspect, but I don't recall all of the > details) > made it so that decision wasn't as firm IIRC. I think that we still have all > of the move functions in ranges though, and getting rid of them was one of > the > main goals of assuming that postblits was cheap. So, I really don't know what > the situation with all that is right now. > > But yes. In general, I believe that save is assumed to be fairly cheap.
Ok, thanks. That cleared things up -- at least to the extent possible. :) -Lars _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
