On May 16, 2011, at 12:01 PM, Mehrdad wrote:
>
> Sean:
>> Removing and then appending one element to an array won't cause any
>> allocations to occur.
>
> How is that possible, though? (See the example in my response to Timon.)
I wasn't thinking about how remove() worked. You'd have to adjust
On 5/16/2011 1:22 PM, Andrei Alexandrescu wrote:
It does seem that all answers were ill-fitted to the way the problem has
been ultimately formulated.
Andrei
Yeah, there's no clean answer to this that's of this form, so I'm just
working around the problem. Thanks everybody for your input, I
a
On Mon, 16 May 2011 23:22:21 +0300, Andrei Alexandrescu
wrote:
On 5/16/11 3:15 PM, Vladimir Panteleev wrote:
On Mon, 16 May 2011 23:11:50 +0300, Andrei Alexandrescu
wrote:
I tested the function above.
OP's intention was to create a version of removeAt which modifies the
array in-place o
On Mon, 16 May 2011 16:17:45 -0400, Mehrdad wrote:
On 5/16/2011 1:15 PM, Vladimir Panteleev wrote:
On Mon, 16 May 2011 23:11:50 +0300, Andrei Alexandrescu
wrote:
I tested the function above.
OP's intention was to create a version of removeAt which modifies the
array in-place only when the
On 5/16/11 3:15 PM, Vladimir Panteleev wrote:
On Mon, 16 May 2011 23:11:50 +0300, Andrei Alexandrescu
wrote:
I tested the function above.
OP's intention was to create a version of removeAt which modifies the
array in-place only when there are no other aliases towards the data.
The initial ap
On Mon, 16 May 2011 16:14:33 -0400, Timon Gehr wrote:
Steven Schveighoffer wrote:
On Mon, 16 May 2011 15:52:23 -0400, Mehrdad
wrote:
On 5/16/2011 12:53 PM, Timon Gehr wrote:
In fact I even need to take that back. In order to work correctly,
the
function would have to iterate downwards.
On 5/16/2011 1:15 PM, Vladimir Panteleev wrote:
On Mon, 16 May 2011 23:11:50 +0300, Andrei Alexandrescu
wrote:
I tested the function above.
OP's intention was to create a version of removeAt which modifies the
array in-place only when there are no other aliases towards the data.
The initial
On Mon, 16 May 2011 23:11:50 +0300, Andrei Alexandrescu
wrote:
I tested the function above.
OP's intention was to create a version of removeAt which modifies the
array in-place only when there are no other aliases towards the data. The
initial approach was to attempt to check if the pas
Steven Schveighoffer wrote:
> On Mon, 16 May 2011 15:52:23 -0400, Mehrdad wrote:
>
>> On 5/16/2011 12:53 PM, Timon Gehr wrote:
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 emi
Andrei Alexandrescu wrote:
> A On 5/16/11 3:04 PM, Mehrdad wrote:
>> On 5/16/2011 12:59 PM, Andrei Alexandrescu wrote:
>>> On 5/16/11 2:56 PM, Timon Gehr wrote:
>>> I think it would take less time to actually paste the function in a file
>>> and try it. A cute possibility:
>>>
>>> void removeAt(T)(
On 5/16/11 3:04 PM, Mehrdad wrote:
On 5/16/2011 12:59 PM, Andrei Alexandrescu wrote:
On 5/16/11 2:56 PM, Timon Gehr wrote:
I think it would take less time to actually paste the function in a file
and try it. A cute possibility:
void removeAt(T)(ref T[] arr, size_t index)
{
copy(retro(arr[0 .. i
On Mon, 16 May 2011 15:52:23 -0400, Mehrdad wrote:
On 5/16/2011 12:53 PM, Timon Gehr wrote:
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...
Andr
On 5/16/2011 12:59 PM, Andrei Alexandrescu wrote:
On 5/16/11 2:56 PM, Timon Gehr wrote:
I think it would take less time to actually paste the function in a file
and try it. A cute possibility:
void removeAt(T)(ref T[] arr, size_t index)
{
copy(retro(arr[0 .. index]), retro(arr[1 .. index + 1]));
foreach is a very bad choice for solving this. I blindly took it over from the
original code. Need to get some sleep :).
This now definitely works, and is also the shortest:
void removeAt(T)(ref T[] arr, size_t index){
for(auto i = index; i; i--) arr[i] = arr[i - 1];
arr = arr[1 .. $];
}
On 5/16/11 2:56 PM, Timon Gehr wrote:
Timon Gehr wrote:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; retro(arr[1 .. index+1]))
item = arr[i - 1];
arr = arr[1 .. $];
}
Sorry, still wrong:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref
On 5/16/2011 12:53 PM, Andrei Alexandrescu wrote:
On 5/16/11 2:44 PM, Mehrdad wrote:
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.
Oh yeah good point.
Is there any way to find out if an array is a slice of anothe
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
h
On Mon, 16 May 2011 15:53:38 -0400, Timon Gehr wrote:
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
Whoops, you are right:
void remov
Timon Gehr wrote:
> void removeAt(T)(ref T[] arr, size_t index)
> {
>foreach (i, ref item; retro(arr[1 .. index+1]))
> item = arr[i - 1];
> arr = arr[1 .. $];
> }
Sorry, still wrong:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; retro(arr[1 .. index+1]))
On 5/16/2011 12:53 PM, Timon Gehr wrote:
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
Whoops, you are right:
void removeAt(T)(ref T[]
> 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
Whoops, you are right:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i,
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
On 5/16/2011 12:38 PM, Andrei Alexandrescu wrote:
Oh, I see.
Wait, what bug are you referring to, though?
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
On 5/16/11 2:38 PM, Andrei Alexandrescu wrote:
On 5/16/11 2:31 PM, Mehrdad wrote:
On 5/16/2011 12:25 PM, Andrei Alexandrescu wrote:
On 5/16/11 2:25 PM, Timon Gehr wrote:
Mehrdad wrote:
Timon:
What about:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; arr[1 .. index+1])
On Mon, 16 May 2011 15:23:31 -0400, Mehrdad wrote:
Steven:
You need to do arr.assumeSafeAppend(); Otherwise, the runtime is no
aware of your invalidation of the last element.
See my edit on SO: http://stackoverflow.com/q/6015008/541686
I'm not an SO user, so I'll post my answer here:
ass
On 5/16/11 2:31 PM, Mehrdad wrote:
On 5/16/2011 12:25 PM, Andrei Alexandrescu wrote:
On 5/16/11 2:25 PM, Timon Gehr wrote:
Mehrdad wrote:
Timon:
What about:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; arr[1 .. index+1])
item = arr[i - 1];
arr = arr[1 .. $]; //note how
On 2011-05-16 12:26, Mehrdad wrote:
> On 5/16/2011 12:25 PM, Timon Gehr wrote:
> > Mehrdad wrote:
> >> Timon:
> >>> What about:
> >> void removeAt(T)(ref T[] arr, size_t index)
> >> {
> >>
> >> foreach (i, ref item; arr[1 .. index+1])
> >>
> >> item = arr[i - 1];
> >>
> >>
On 5/16/2011 12:25 PM, Andrei Alexandrescu wrote:
On 5/16/11 2:25 PM, Timon Gehr wrote:
Mehrdad wrote:
Timon:
What about:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; arr[1 .. index+1])
item = arr[i - 1];
arr = arr[1 .. $]; //note how no valid data is beyond the end of
On Mon, 16 May 2011 15:16:16 -0400, %u wrote:
Timon:
What about:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; arr[1 .. index+1])
item = arr[i - 1];
arr = arr[1 .. $]; //note how no valid data is beyond the end of
the array
}
Clever, but if you do this wi
On 5/16/2011 12:25 PM, Timon Gehr wrote:
Mehrdad wrote:
Timon:
What about:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; arr[1 .. index+1])
item = arr[i - 1];
arr = arr[1 .. $]; //note how no valid data is beyond the end of the array
}
Clever, but if yo
Mehrdad wrote:
> Timon:
> > What about:
> void removeAt(T)(ref T[] arr, size_t index)
> {
>foreach (i, ref item; arr[1 .. index+1])
> item = arr[i - 1];
> arr = arr[1 .. $]; //note how no valid data is beyond the end of the array
> }
>
> Clever, but if you do this with a big enough
Steven:
> You need to do arr.assumeSafeAppend(); Otherwise, the runtime is no
aware of your invalidation of the last element.
See my edit on SO: http://stackoverflow.com/q/6015008/541686
On Mon, 16 May 2011 15:12:17 -0400, Timon Gehr wrote:
As an example, let's say I define:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; arr[index .. $ - 1])
item = arr[i + 1];
arr = arr[0 .. $ - 1];
}
and then I have:
auto arr = [1, 2, 3];
arr.removeAt(0)
Timon:
> What about:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; arr[1 .. index+1])
item = arr[i - 1];
arr = arr[1 .. $]; //note how no valid data is beyond the end of
the array
}
Clever, but if you do this with a big enough number of items, you'll
exhaust al
> 1. Are you sure you need an array rather than a linked list?
>
> Yes. I'm only asking about a functionality already present in every other
language I know (C++'s vector.erase,
> C#'s List.RemoveAt, Java's removeAt) so it's not something out of the blue. ;)
>
> 2. The garbage collector guarantees
On Mon, 16 May 2011 14:53:21 -0400, Andrei Alexandrescu
wrote:
On 5/16/11 1:29 PM, Mehrdad wrote:
As has been mentioned, std.algorithm.remove can be of help. You may
want to look at three of its
capabilities in particular: (a) remove multiple offsets in one pass,
e.g. remove(a, 0, 4) remo
Andrei:
> After you remove some elements from an array by using std.algorithm.remove,
> the array capacity stays the
same.
Sean:
> Removing and then appending one element to an array won't cause any
> allocations to occur.
How is that possible, though? (See the example in my response to Timon.)
1. Are you sure you need an array rather than a linked list?
Yes. I'm only asking about a functionality already present in every other
language I know (C++'s vector.erase,
C#'s List.RemoveAt, Java's removeAt) so it's not something out of the blue. ;)
2. The garbage collector guarantees amortized
You could try checking capacity() and using reserve() in non time-critical code.
On 5/16/11 1:29 PM, Mehrdad wrote:
As has been mentioned, std.algorithm.remove can be of help. You may want to
look at three of its
capabilities in particular: (a) remove multiple offsets in one pass, e.g.
remove(a, 0, 4) removes
the first and fifth element, (b) you can remove subranges, e.g.
On Mon, 2011-05-16 at 18:45 +, Timon Gehr wrote:
[ . . . ]
>
> What exactly do you need the data structure for?
I have to admit, my reaction was, "and about b~ time someone asked
that question". How on earth can one answer a question about data
structures without knowing what the use cas
> Thanks for the idea. This seems great, except for a couple of things:
>
> - I _do_ need the order to stay the same, so I can't just put in the last
> element.
>
> - I only need to remove one element at a time.
>
> - I still don't understand how this helps. Either this modifies the array
directly
On May 16, 2011, at 11:29 AM, Mehrdad wrote:
>
>> As has been mentioned, std.algorithm.remove can be of help. You may want to
>> look at three of its
> capabilities in particular: (a) remove multiple offsets in one pass, e.g.
> remove(a, 0, 4) removes
> the first and fifth element, (b) you can r
> They're called Arrays, not Lists (or ArrayLists), so way would you expect a
> delete functions?
I thought they're supposed to substitute for lists (otherwise we'd have an
ArrayList type in
Phobos).
> If you want something like an ArrayList in D, have a look at
> std.container.Array :-)
Tha
On 05/16/2011 04:54 AM, Mehrdad wrote:
Hi!
I posted this question on StackOverflow about D:
http://stackoverflow.com/questions/6015008/how-to-delete-an-element-
from-an-array-in-d
and the answers are quite surprising to me.
Are arrays really supposed to be substitutes for array lists if we
ca
On Mon, 16 May 2011 12:54:33 +0300, Mehrdad wrote:
Hi!
I posted this question on StackOverflow about D:
http://stackoverflow.com/questions/6015008/how-to-delete-an-element-
from-an-array-in-d
and the answers are quite surprising to me.
I've updated my answer. Sorry my original answer wasn'
Am 16.05.2011 11:54, schrieb Mehrdad:
> Hi!
>
> I posted this question on StackOverflow about D:
>
> http://stackoverflow.com/questions/6015008/how-to-delete-an-element-
> from-an-array-in-d
>
> and the answers are quite surprising to me.
>
> Are arrays really supposed to be substitutes for arr
Hi!
I posted this question on StackOverflow about D:
http://stackoverflow.com/questions/6015008/how-to-delete-an-element-
from-an-array-in-d
and the answers are quite surprising to me.
Are arrays really supposed to be substitutes for array lists if we
can't remove anything from them? It seems t
48 matches
Mail list logo
