Boost logo

Boost :

Subject: Re: [boost] lifetime of ranges vs. iterators
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-03 19:46:14


on Wed Sep 03 2008, Arno Schödl <aschoedl-AT-think-cell.com> wrote:

>> > This "skipping" in recursion needs exceptions. Exceptions are the only
>> > means C++ gives us to "jump" in a recursive environment.
>
>> I don't know what recursion you are referring to.
>
> The stack of adaptors calling each other.

That's not recursion, FWIW.

>> Only for the non-exceptional path.
>
> Too bad.
>
>> but I have no practical experience.
>
>> My advice: forget exceptions. They're totally inappropriate in this
>> context IMO.
>
> IMO, you need some sort of jump to solve the repeated end-checking
> problem.

I think if you hand-code an iterator that is semantically equivalent to
the one that results from one of your stackings, you will see that no
such "jump" is required.

> If the base iterator end check is nested into functions, the only way
> to transport this information out is via exceptions. If you don't like
> exceptions,

Me, not like exceptions? I hope that's a joke!

> the "I am at the end of the underlying sequence" information must be
> generated at the outermost level of the function tree. If it is
> generated anywhere else, there is simply no way to transport the
> information out without checking the return value of a function, which
> is the extra check we want to avoid. Do we agree?

I think the optimizer can remove some redundant tests if the functions
are inlined. But, that said, I am becoming more and more convinced as
this discussion goes on that compressing stacked iterator adaptors is
barking up the wrong tree if you care about efficiency. The difference
between the code generated in the abstracted case and the code you'd
write by hand is simply too great.

No, I don't have a picture of a better solution yet. But it's an
interesting problem.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk