On 5/16/11 2:44 PM, Mehrdad wrote:
On 5/16/2011 12:41 PM, Andrei Alexandrescu wrote:
I was mistaken and removed my post. The code ingeniously redefines the
problem - instead of removing from the array by shifting its tail
downwards, it shifts elements upwards from the head of the array. A nice
hack, but I don't think it does a lot in helping your situation.
In fact I even need to take that back. In order to work correctly, the
function would have to iterate downwards. It _is_ indeed buggy, and I
should stop emitting opinions when I'm short on time...
Andrei
I'm not sure what you mean by iterating downwards, but I just noticed
another bug: That would _still_ stomp over a superarray if this array is
a slice of it, right?
Iterating downwards would mean: if you want to remove the third element
from
a = [0, 1, 2, 3, 4];
by using head shifting, you'd need to assign a[2]=a[1], a[1]=a[0]
(backwards that is) to obtain [0, 0, 1, 3, 4]. Then you take a[1 .. $]
which is the result.
The function as implemented first assigns a[1]=a[0] and then a[2]=a[1],
leading to [0, 0, 0, 3, 4] which is not what's needed.
Is there any way to find out if an array is a slice of another array?
No. If there would, it would be a rather advanced function. Allow me to
reiterate my suggestion: it's likely you have a simple problem with a
simple solution based on slices, which are a simple abstraction.
Therefore I suggest you rethink a bit of your design, and it's possible
you won't need assumeSafeAppend et al.
Andrei
