Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-01 14:32:42

Giovanni Piero Deretta wrote:

> I still do not see how can you 'fix' BOOST_TYPEOF to deduce const
> references correctly.
> Without that, you can't implement result_of with boost typeof.

As written elsewhere, treating a const rvalue as though it were a const
lvalue should almost never cause a serious problem.  It wouldn't be
perfect, but it would work in a vast majority of cases.

> you can use rewrite rules to simplify ranges of ranges, but in the
> end, you want to do a smarter traversal to eliminate all abstraction
> overhead (exactly for the same reason you would use a segmented
> iterator-aware for_each).

Ah.

> I shouldn't have called it for_each, but an optimizing range library
> should provide an internal iteration interface that takes care of
> eliminating as much abstraction as possible. It would in practice be a
> boost::for_each. Any algorithm that can be implemented on top of it
> (and I guess that there are many, consider that you can use lazy zip,
> map and filter) would benefit from it.

OK.

>>> I think that the basic ranges that should (at least) be supported are:
>>>
>>>    - mapped_range
>>>    - filtered_range
>>>    - taken_range (i.e. just the first n elements of a range)
>>>    - taken_while_range (i.e. the first elements such as a predicate is true)
>>>    - zipped_range
>>>    - unfold_range (with which you can pretty much express any other
>>> range, see http://tinyurl.com/5mus25)
>>>
>>> An eventual 'drop' (take all the elements after the first n) and
>>> 'drop_while' (drop the first elements such as a predicate is true)
>>> probably need strict evaluation anyway and aren't worth supporting
>>> explicitly.
>>>
>>> Finally, what do you mean that range_ex views should be lazier? Lazier
>>> than what?
>> Lazier than they are.  If you avoid building the iterators until you
>> have the whole chained view expression, you can do some optimizations
>> like I mentioned above.  Again, though, this probably isn't really
>> important.
> 
> Ah, ok. Would this just be a matter of deferring the iterator
> construction only in at an explicit call to begin()/end() over, for
> example, a strided_range, or you have in mind something more complex?
> (I think the domain you are thinking of is numeric computations, mine
> is text processing)

Probably something more complex, but I really don't want to drag this
point out :-)

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