Re: lifetime of ranges vs. iterators

on Sat Aug 30 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:

> Hum, this would means that every range needs to know how to construct
> and deconstruct iterators of other ranges, at least if it wants to
> guarantee that the minimum space possible is used.

It would be done with associated types and functions of the iterators.
Few iterators need to store that kind of redundant information, but when
you build an iterator type that *does*, it would be deemed "polite" to
specialize an appropriate trait and/or define the corresponding
overloads to allow it to be decomposed/re-composed.

I've been itching to rework Boost.Iterator recently, and this could make
a very nice enhancement.

> It seems a bit complex, and there would be a need to come up with some
> non obvious protocol to do that (some sort of compile time
> introspection on ranges).

Not on ranges; just on iterators.

> Is it really worth it? Are you advocating it, or it was just another
> solution to consider?

I think I may be advocating it 

I think there may be some relationship between this and hierarchical
iterator representation, so I'd like to explore it further from that
angle as well.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost