On Thursday, 29 May 2014 at 12:45:20 UTC, Adam D. Ruppe wrote:
On Thursday, 29 May 2014 at 10:28:45 UTC, Chris wrote:
I dug into Chapter 3 about ranges. It clarifies a lot of things about ranges.


Yeah, a lot of the stuff there comes from my own process when writing my first range consuming function (which is still in a pretty ugly form in my sha.d on github, I have never really fixed it).

I have different types of range implementations throughout my code now, which basically depicts the learning process while I was trying to grasp the concept. I think the D website could do with something like your Chapter 3. It's not really rocket science, but when you have no guidelines, best practices whatsoever, you have to experiment yourself which always leaves a weird after taste, i.e. questions like "is this really the right way? am I doing something wrong?".

I had to ask on the newsgroup: what does it really mean to accept a generic input range? Does it mean to attempt data transformations to receive anything? Or is it semi-strict? (the answer is to take any input range but be strict on the element type - don't try to transform it yourself as that introduces bugs and hidden performance issues for the algorithm's user)

Yes, I always adhered to this rule.

I didn't quite understand the answer until some time later and now I think it is fairly simple, but since I was so wrong about it for such a long while I figured other people probably had the same problems and tried to cover them in the book.

True, true. Your book was direly needed, and if it's just to clarify things. Sometimes I would feel like a fool to ask questions about ranges, thinking everybody understands them except for me. Once you get the hang of it, it's pretty straight forward.

One of the sections there talks about emulating random access on a structure that doesn't really support it (a linked list) and focuses on the hidden performance. That's the range-writer side of the same range-consumer rule: don't try to get fancy and support something the underlying data doesn't natively do because then you'll introduce bugs and slowdowns that might be hard to find.

Reply via email to