Re: [boost] lifetime of ranges vs. iterators

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-02 11:22:32

On Tue, Sep 2, 2008 at 5:02 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> on Tue Sep 02 2008, Arno Schödl <aschoedl-AT-think-cell.com> wrote:
>
>>
>> The RangeEx documentation writes something like "what algorithms are to
>> containers, adaptor ranges are to ranges". Whenever you are applying one
>> (non-permutating) algorithm to a container, and then another and then another,
>> you can stack range adaptors. It's like lazy evaluation of a Haskell list.
>
> Sheesh; give me a little credit, please.  I know what range adaptors do.
>
>> Looking through our code for adaptor ranges, I find:
>>
>> unique_range
>> union_range
>> difference_range
>> filter_range
>> concat_range
>>
>> These ranges are all actually used in our program. All these ranges need an end
>> iterator, and any stacking of any combination of these ranges leads to the
>> problems we are discussing here. I don't find this impractical.
>
> You're missing my point.  Are you indeed making such stacks?  If so,
> what are you doing with them?

The deepest stack I have in my application is 4 adapters deep. The
reasons I do not have deeper stack are:

1) compile time cost
2) lack of auto and decltype for easy factorization (need to 'reify'
the ranges at function boundaries)
3) lack of time to make additional lazy wrappers for standard algorithm.

I expect that with a C++0x compiler 1 [*] and 2 won't be a problem,
while RangeEx should take care of 3.

The usage is in a real world text processing heavy application.

[*] mostly due to variadics templates and rvalue refs.
-- 
gpd