Re: [boost] lifetime of ranges vs. iterators

From: Neil Groves (neil_at_[hidden])
Date: 2008-09-02 12:00:15

Arno,

On Tue, Sep 2, 2008 at 4:38 PM, Arno Schödl <aschoedl_at_[hidden]> wrote:

> > > The RangeEx documentation writes something like "what algorithms are to
> > > containers, adaptor ranges are to ranges". Whenever you are applying
> one
> > > (non-permutating) algorithm to a container, and then another and then
> another,
> > > you can stack range adaptors. It's like lazy evaluation of a Haskell
> list.
>
> > Sheesh; give me a little credit, please.  I know what range adaptors do.
>
> So why are you asking these questions then? With smart compilers, generic
> programming is supposed to produce code that is pretty close to handcrafted
> code. That is what people expect, and that is what generic programming is
> sold on. The current range adaptors were far from it. And even if stacks
> don't exceed size 3 or 4 in practice, which is all I have in my code, why
> produce code that is factor 8 or 16 slower or more storage-bloated than
> necessary? As we have seen, the reason was not that the problem is
> intractable with generic programming. It just took a little thought to do it
> right.
>

Please do not get frustrated. We all want to improve Range / RangeEx. I have
to apologise for not offering to modify the code sooner. I have been
watching, and learning. Once I have understood the design alternatives and
have fully comprehended the optimum solution I will implement the suggested
improvements. It looks like I will need to coordinate with the Iterator
library developers for the optimum solution. So far RangeEx has not made it
into Boost, and thus asking for changes in other libraries before seemed
unlikely to succeed. While I accept that the adaptors are possibly not the
optimum solution they are at least implementations of the functionality. I
would gladly accept superior contributions ;-). I am also happy to spend
more time improving them myself. I have to apologise for slow response
times, my full-time job simply doesn't allow me enough time to contribute to
this discussion as much as I probably ought to. You have made some very
valid technical points, let's focus on these please.

> --
> Dr. Arno Schoedl · aschoedl_at_[hidden]
> Technical Director
>
> Best wishes,
Neil Groves