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