It is the year 2020: why should I use / learn D?
Steven Schveighoffer
schveiguy at gmail.com
Wed Nov 14 18:27:54 UTC 2018
On 11/14/18 1:08 PM, Eugene Wissner wrote:
> On Wednesday, 14 November 2018 at 17:47:10 UTC, Basile B. wrote:
>> On Wednesday, 14 November 2018 at 16:09:32 UTC, Eugene Wissner wrote:
>>> No, it wasn't the reason. Some algorithms cannot be implemented with
>>> ranges as efficient as with iterators.
>>>
>>> "In other words, by converting the is_word_boundary from iterators to
>>> D-style ranges, the algorithm goes from O(1) to O(N). From this we
>>> draw the following conclusion: D’s choice of algorithmic basis
>>> operations is inherently less efficient than C++’s."
>>>
>>> C++ iterators are more flexible.
>>
>> You meant D ?
>
> C++. An iterator points to some element in a range, and you can mix it
> as you need. In D you always have two iterators: beginning and the end
> of the range. The feature I miss most, is a bidirectional iterator. In
> C++ you can go back and forth with this iterator. In D if you do popBack
> there is no way back (or front :)); with popFront you can't reach the
> element after back, even if there such elements, you have to take an
> another range from the container.
What you need is an index in a range. The inherent thing about a naked
iterator (bidirectional or otherwise) is it's not safe. It's super easy
to get into UB territory.
> D ranges are more compact, because you need the begining and the end in
> the most cases, so such functions just take one range instead of two
> iterators. But there are still a lot of cases where D ranges don't work.
It's also much easier to avoid invalid situations with a range vs.
carrying around 2 iterators. Indeed there are very few cases for
algorithms that need 3 reference points. But where iterators are great
are simply as a pointer to an item in a container (see below).
>
> Steven Schveighoffer mentioned an interesting solution but it adds
> complexity: Implement Range, ConstRange, Cursor, ConstCursor?,
> algorithms that accept ranges or cursors and so forth...
Ugh, that's an issue with D and tail-const. You really should never need
multiple functions for those things, it should just be Range and Cursor,
and the tail-modified versions should be handled by the language.
But one thing cursors (at least the ones I implemented) don't solve is
the bidirectional nature -- a cursor is inherently not really movable.
It needs boundaries to prevent Bad Things, and existentially you don't
*want* boundaries for a cursor, because boundaries change.
The most common use case I had for a cursor was keeping a reference to
an element in a container. At various points, I wanted to refer to that
element to use it, possibly to restructure the container, I didn't want
to have to search for it again. But if you use an actual range for this,
you now have *two* elements you are pointing at (the beginning and the
end). It's entirely possible for that relationship to change or become
invalid. With a cursor, it can't become invalid because you are only
pointing at one spot.
-Steve
More information about the Digitalmars-d
mailing list