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