std.container & ranges

[Ary Manzana]

On 11/2/11 8:48 AM, Steven Schveighoffer wrote:
> On Tue, 01 Nov 2011 16:53:26 -0400, Max Wolter <awishformore at gmail.com>
> wrote:
>
>> On 10/30/2011 9:28 PM, Jonathan M Davis wrote:
>>> On Sunday, October 30, 2011 20:53:02 Max Wolter wrote:
>>>> Hello there.
>>>>
>>>> Thank you very much for the explanation.
>>>>
>>>> However, while I really liked the concept of ranges in Andrei's book
>>>> and
>>>> a lot of it seems intuitive and faster than using iterators, I can't
>>>> shake the feeling that in this case, it's just unnecessarily
>>>> convoluted.
>>>>
>>>> Maybe it's just the fact that the container library is still very
>>>> basic,
>>>> but I don't think I should go through such a complicated procedure to
>>>> remove an known element from a list. It's just not a "very simple" or
>>>> intuitive solution, which is something I came to love D for thus far.
>>>
>>> You would be doing exactly the same thing in C++ except that it would
>>> be with
>>> an iterator rather than a range. You would use find to find the
>>> iterator to the
>>> element that you wanted and then you'd pass that to the list's erase
>>> function.
>>> It is only more complicated in D in that you get a range which
>>> _starts_ with
>>> the element that you want (essentially, you get the iterator to that
>>> element
>>> plus the end iterator for the list), so if you want to remove only
>>> the first
>>> element, you take it from the front of the range. Other than that,
>>> it's the
>>> same as in C++. You can't remove an element from a list in C++ by
>>> giving that
>>> element to the list anymore than you can in D. In both cases, you
>>> need an
>>> iterator or a range.
>>>
>>> So, in comparison to C++, there's no significant difference. Now,
>>> Java does have
>>> a remove function which will take an element and remove the first
>>> occurence of
>>> that element from a list, and we could theoretically add one, but
>>> why? It
>>> would just be duplicating the functionality that find already gives.
>>> Java
>>> doesn't use iterators the way the C++ does, and it doesn't have
>>> ranges, so it
>>> _can't_ have a find function the way that C++ and D do, but D can.
>>> And in some
>>> cases, find can do it more efficiently than your loop could have.
>>>
>>> I grant you that if you're not used to using find like this in C++
>>> (and far,
>>> far too many C++ programmers use loops instead of find - in part
>>> because pre-
>>> C++11, there were no lambdas and any time you need a custom comparison
>>> function, it's a pain to get one), then it's not immediately
>>> intuitive, but
>>> it's far more flexible and powerful than removing elements by giving the
>>> element to a remove function on the list. And if you really want to
>>> use a
>>> loop, then you still can. You just can't use foreach.
>>>
>>> for(auto r = organism[]; !r.empty; r.popFront())
>>> {
>>> if(r.front.x == x&& r.front.y == y)
>>> {
>>> organism.stableLinearRemove(take(r, 1));
>>> break;
>>> }
>>> }
>>>
>>> but that's a lot more verbose than simply using find, and as I said,
>>> in at
>>> least some cases, find can be more efficient than simply looping,
>>> since it's
>>> optimized for finding elements.
>>>
>>> - Jonathan M Davis
>>
>> Hello again.
>>
>> I've read all further replies in this thread, but it seems to me this
>> is the most appropriate place to respond.
>>
>> Simply put, all of those options are too verbose. If what you want to
>> do is simple, the syntax should also be simple, this is what I love
>> about D. As a side-note, I don't come from Java, but I still expect a
>> container to be able to remove an element by passing it to a method.
>> The verbosity and the details of this operation should be hidden in
>> the implementation of the method and I shouldn't need to know about
>> the details. Otherwise, I could just as well implement my own container.
>
> The basic response to this is, when dealing with containers generically
> (that is, you know you have a container, but you don't know what type),
> the "remove this element" operation is not necessarily a good primitive
> to have.
>
> Simply because from the myriad of containers, only some can implement
> this operation efficiently. Java embeds this operation in the interface,
> which means any interface you have to a container could potentially use
> O(n) time to remove that element. Such an innocuous piece of syntax
> *should* have a cost if it's not efficient IMO.
>
> BTW, the original question doesn't provide enough information to say
> "remove this element." Even in Java, if you aren't using the default
> comparison, you must use a comparator method to determine which one to
> remove. If cell.x == x && cell.y == y *is* the comparison operator for
> the type, then the syntax gets much simpler, because you don't need to
> pass a specialized comparison function.
>
> In dcollections, removing a specific element (using the default
> comparison operator for that element) on a *fast lookup* container is as
> simple as:
>
> container.remove(container.find(x));
>
> Which removes the element x if it's found. However, this is not defined
> for containers which use O(n) time to search (such as linked list), you
> must use std.algorithm.find for that:
>
> container.remove(find(container[], x).begin);
>
> Should work, and takes O(n) time.
>
> -Steve

I don't really understand what's wrong with inefficient methods. You can 
have inefficient methods that are convenient, like removing an element 
by the default comparison, or giving it a delegate to match the 
element(s) to remove.

You profile your application. Is that method the bottle-neck? If so, you 
change it to a more efficient one. If not, you are happy you had that 
method there, performing in an inefficient way, but which doesn't matter 
that much compared to, say, opening an SQL connection.

Programmers want to program, fast. They have schedules, they need to 
deliver. They don't need to always find the best solution. They can find 
a compromise between "working" and "fast", move on, and later profile 
and worry about what matters most.

Programmers don't want to fight with the language or think "Oh, so to 
remove an element I need to use this operation and combine it with that 
one and with that other one"...