On Mon, 03 Jun 2013 23:38:12 -0400, Peter Williams
<pwil3...@bigpond.net.au> wrote:
On 04/06/13 11:56, Steven Schveighoffer wrote:
On Mon, 03 Jun 2013 20:06:14 -0400, Peter Williams
auto tmp = a[i + 1..$];
a.length = i;
a ~= tmp;
would be more efficient?
No, because that will also reallocate,
Wouldn't the a.length = i prevent that?
No. The runtime specifically will reallocate on this case.
It does not know that tmp is never going to be used again, nor does it
know that there aren't any other references to the data past i. It MUST
reallocate to avoid stomping (in fact, prior to my changes it DID
overwrite).
Case in point, if it didn't reallocate, the above would be copying tmp
over itself, offset by one!
The runtime expects that when it is appending data, it is doing so into
space that is currently unused. You can use assumeSafeAppend to tell it
"the data after this is unused", but then it better be unused :) In your
case, you are using it (via tmp), so that doesn't work.
For some reason, D doesn't support overlapping moves,
Probably because there's some instances where it would be a disaster and
explaining all the cases where you can and can't becomes too difficult
so it's just easier to say no to all cases.
No, memmove is valid C code and supports overlapping writes. It's not as
optimized as memcpy, which does not.
But I don't know exactly what the difference is. A simple check at the
beginning can determine which mode to use, memmove should devolve to
memcpy if there is no overlap. And in some cases, the compiler
specifically knows whether there is overlap at compile time.
-Steve
