ch-ch-changes

Denis Koroskin 2korden at gmail.com
Wed Jan 28 01:52:03 PST 2009


On Wed, 28 Jan 2009 07:15:25 +0300, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> I've worked valiantly on defining the range infrastructure and making  
> std.algorithm work with it. I have to say that I'm even more pleased  
> with the result than I'd ever expected when I started. Ranges and  
> concepts really make for beautiful code, and I am sure pretty darn  
> efficient too.
>
> There's a lot to sink one's teeth in, but unfortunately the code hinges  
> on a compiler fix that Walter was kind enough to send me privately. I  
> did document the work, but the documentation doesn't really make justice  
> to the extraordinary possibilities that lay ahead of us. Anyhow, here's  
> a sneak preview into the up-and-coming ranges and their algorithms.
>
> http://ssli.ee.washington.edu/~aalexand/d/web/phobos/std_range.html
> http://ssli.ee.washington.edu/~aalexand/d/web/phobos/std_algorithm.html
>
> Ranges are easy to define and compose efficiently. It was, however, a  
> pig to get a zip(r1, r2, ...) working that can mutate back the ranges it  
> iterates on. With that, it's very easy to e.g. sort multiple arrays in  
> parallel. Similarly, chain(r1, r2, ...) is able to offer e.g. random  
> iteration if all components offer it, which means that you can do crazy  
> things like sorting data that sits partially in one array and partially  
> in another.
>
> Singly-linked list ranges are in, and to my soothing I found an answer  
> to the container/range dichotomy in the form of a topology policy. A  
> range may or may not be able to modify the topology of the data it's  
> iterating over; if it can, it's a free-standing range, much like  
> built-in arrays are. If it can't, it's a limited range tied to a  
> container (of which I defined none so far, but give me time) and it's  
> only the container that can mess with the topology in controlled ways.  
> More on that later.
>
> Feedback welcome.
>
>
> Andrei

Sweet!

One note - "move" has a precondition: "!pointsTo(source, source)". Shouldn't it be "!pointsTo(source, target)"?






More information about the Digitalmars-d mailing list