Boost logo

Boost :

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

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