We need to rethink remove in std.container
Lutger Blijdestijn
lutger.blijdestijn at gmail.com
Tue Feb 22 06:38:04 PST 2011
Steven Schveighoffer wrote:
> On Mon, 21 Feb 2011 21:55:20 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
> wrote:
>
>> Okay, removing elements from a container sucks right now. You can do
>> stuff like
>> removeAny (generally pretty useless IMHO) or removeFront just fine, but
>> removing
>> an arbitrary range from a container just plain sucks.
>>
>> remove takes a range type which is the range type for the container that
>> it's
>> on. That makes sense. It's obviously not going to be able to a take an
>> arbitrary
>> range and remove that from itself. How would it know which elements in
>> that
>> range corresponded to which elements in itself - especially when it
>> could be a
>> range which skips elements or something similar? So, _that_ part makes
>> sense.
>>
>> But have you actually tried to get a range of the appropriate type to
>> remove
>> from a container? It seems like almost ever function in std.range and
>> std.algorithm returns a new range type, making them completely useless
>> for
>> processing a range to be removed from a container.
>>
>> I was looking to remove a single element for a RedBlackTree. The best
>> function
>> that I could think to get the proper range was findSplit. The middle
>> portion of
>> the return value would be the portion that I was looking for. I'd take
>> that and
>> pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its
>> implementation and the first two portions of the result of findSplit
>> aren't the
>> right range type.
>
> RedBlackTree supports the equalRange function, which gives you a range of
> elements equal to the value you give.
>
oo how I missed that. When you are working on RedBlackTree, would you please
consider putting an example in the doc that uses it to this effect?
More information about the Digitalmars-d
mailing list