Improving std.algorithm.find

[Dmitry Olshansky]

On 20.07.2010 0:05, Philippe Sigaud wrote:
> On Mon, Jul 19, 2010 at 21:23, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>> 
> wrote:
>
>
>         What I personally would like is a way to find an element in an
>         ordered
>         container (binary tree...)
>
>
>     Wouldn't that be a member of the binary tree?
>
>
> Yes, indeed. Unless I define some cousin to range, a recursive range, 
> to iterate on any recursive container, like trees or graphs and then 
> devise algorithms on them. I played with this idea a few weeks ago but 
> went to do other things. Anyway, carry on.
> Btw, I still plan to update some simple generic graphs and trees 
> structs to obey TotalContainer interface when it makes sense, and 
> update my graph algorithms accordingly. If I ever get somewhere, I'll 
> post something.
>
>
>            Aren't such scenarios better served by putting the limits
>         inside the
>            predicate? Otherwise the list of what can be done could go
>         on forever.
>
>
>         The problem is that, as the predicate is passed at
>         compile-time, the
>         limits must be CT-defined too. I'd like the limits to be
>         defined at
>         runtime. I run into this regularly, while using predicates in
>         std.algorithms.
>
>
>     I think this is a misunderstanding. All of std.algorithm works
>     with delegates:
>
>
>        int[] a = [ 1, 4, 2, 3 ];
>        int b = 2;
>        assert(find!((x) { return x > b; })(a) == [4, 2, 3]);
>
> Ah yes, but I regularly use algorithms structs as return values, like 
> this:
>
> auto nTimes(E, R)(E multiplier, R range)
> {
>     return map!((ElementType!R e) { return e*multiplier;})(range);
> }
Try this workaround, replacing delegate with nested function, works for me:
auto nTimes(E, R)(E multiplier, R range){
     ElementType!R fun(ElementType!R e) { return e*multiplier; }
     return map!(fun)(range);
}
For some reason, compiler never plays nice with map, and I believe there 
are some issues with current implementation (2.047 release ) that Andrei 
(hopefully) fixed in recent commit.

> Philippe


-- 
Dmitry Olshansky