shifting array slices

[H. S. Teoh]

On Sat, Feb 11, 2012 at 10:30:43AM -0800, Jonathan M Davis wrote:
> On Saturday, February 11, 2012 12:09:32 Ellery Newcomer wrote:
> > I'm pretty sure this used to work:
> > 
> > import std.algorithm;
> > 
> > int[] ra;
> > copy(ra[5 .. 10], ra[4 .. 9]);
> > 
> > and would correctly shift the range [5 .. 10] down one
> > (unlike ra[4 .. 9] = ra[5 .. 10], which is prohibited by spec)
> > 
> > In dmd 2.057 of course it doesn't work; is this a bug or should I be
> > looking elsewhere for this functionality?
> 
> copy uses array copying if it can, which is what I would expect it to
> do. In fact, a comment in copy's source states that doing so results
> in a 10x - 20x improvement in speed over the generic implementation.
> So, I would say that it's safe to say that you can't use copy to copy
> overlapping arrays. I'm not even sure it's a good idea to use
> overlapping ranges. I haven't dealt with output ranges enough to say
> without studying up on them again.
[...]

This brings up an interesting point: what does the GC do if you have an
array that's continually appended to, and also shrunk from the front?
That is:

	ubyte[] buf;
	while ( ... ) {
		consumeData(buf[0]);
		buf = buf[1 .. $];

		ubyte x = getMoreData();
		buf ~= x;
	}

Will such a program "leak memory" in the sense that the memory chunk
allocated to buf will grow larger and larger, even though its initial
segment is never accessed again? Or is the GC smart enough to only
reallocate the needed size when the memory chunk is moved (at some point
when it has no more space to append x)?

If the GC is smart enough, then this kind of construct could be used
instead of copying overlapping ranges.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.