Re: [boost] lifetime of ranges vs. iterators

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

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

>>>> > I'm not there yet, but I know enough about the problem now that I
>>>> > wouldn't "buy" a partial solution.
>>>
>>>> Before I start playing around with the problem, is my throwing
>>> increment_and_dereference optimization fair game? I believe I can't > do
>>> without.
>>>
>>> Since dereference does not need to end-check, throwing increment() is
>>> probably the basic building block. Fair game? 
>>
>>Sorry, I really don't know what you're asking.
>
> A basic multiple-filter loop is this:
>
> filter_increment {
>   for(;;) {
>     ++i;
>     if( empty() || predA( dereference() && predB( dereference ) && predC(
> dereference ) && predD( dereference ) ) break;
>     // <--- towards base_range *** function stack *** towards outermost
> filter_iterator ---->
>   }
> }
>
> If empty() evaluates to true, all pred* are skipped. 

Uh-huh...

> 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.

> At least in Win32, exceptions are slow, probably too slow to be
> practical. I heard that table-based exceptions are much faster,

Only for the non-exceptional path.

> but I have no practical experience.

My advice: forget exceptions.  They're totally inappropriate in this
context IMO.

> Before spending time working on the problem you posed, I want to make
> sure than my solution does not get trashed because I use
> exceptions. 

Trashed, I don't know about that. However, I'm not interested in any
such approach.

> If we want to avoid them, I would say that there is no way to get
> optimal performance with stacked iterators, and I would not even try.

Again, I encourage you to -- at least temporarily -- give up the
assumption that these problems should be solved with stacked iterators
when the costs we're discussing actually matter.

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