On 20.07.2010 0:05, Philippe Sigaud wrote:
On Mon, Jul 19, 2010 at 21:23, Andrei Alexandrescu <seewebsiteforem...@erdani.org <mailto:seewebsiteforem...@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

Reply via email to