Arrays are sufficient for ArrayLists? Really??
Mehrdad
wfunction at hotmail.com
Mon May 16 12:31:44 PDT 2011
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 the
>>> array
>>> }
>>>
>>> Clever, but if you do this with a big enough number of items, you'll
>>> exhaust all memory. Be careful. :P
>>
>> Total memory usage is at most 2 times the maximum size the array
>> reaches during
>> its lifetime. Test it.
>
> Testing would also reveal that this is a buggy replica of
> std.algorithm.remove. At best we should suggest reusing library code
> over attempting to reinvent it.
>
>
> Thanks,
>
> Andrei
>
Oh, I see.
Wait, what bug are you referring to, though?
On 5/16/2011 12:25 PM, Steven Schveighoffer wrote:
>> Steven:
>>> For the OP, you may want to consider using ArrayList from
>> dcollections, which supports removing an individual or range of
>> elements, or using foreach to purge the list. Note that this class
>> does call assumeSafeAppend on its data storage since it can make
>> more assumptions.
>>
>> Ah, seems to be what I need.
>>
>> I guess I was also trying to argue this should really be part of the
>> language too, though (not just Phobos), given that concatenation and
>> even hashtables are also part of the language. It seems to be
>> missing badly. :\
>
> builtin arrays are full of features that are "good enough" for most
> usages. Removing elements the way that is least confusing is
> inefficient, and removing elements the most efficient way can be
> confusing or incorrect depending on the application. Rather than guess
> what the user expects, the runtime just leaves it up to the
> developer/standard lib.
>
> -Steve
Hm... is it really that atypical, though? We already have addition, is
removal really that unlikely of an operation?
More information about the Digitalmars-d
mailing list