Re: [boost] lifetime of ranges vs. iterators

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-02 17:37:37

On Tue, Sep 2, 2008 at 8:27 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> on Tue Sep 02 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
>
>>> 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.
>
> Great, but what are you doing with these stacks?  Normally, the answer
> would be something like "I'm applying the X algorithm to a range of
> elements that represent Y but have been adapted to look like Z"
>

Usually is a matter of converting a text document to a point in a
feature vector space as a preprocessing stage:

Most pipelines start with tokenization, normalization, filtering and
hashing, with a 'take' operation at the end.

The resulting range is usually sorted (which implies breaking the
laziness), unique-ed and augmented with score information (another
map).

I very often need to compute set union and intersection of pair of
these ranges.
[I do not have yet a lazy adaptor for this (actually I do, but is kind
of experimental)].

Most of the uses of lazy ranges are in relatively non performance
critical part of the application, so I do not aim for absolute zero
abstraction overhead.
A nice thing of lazy ranges is that are useful to control peak memory
usage of the application (in fact if you are careful, you can do very
little dynamic memory allocation)

I'm interested in using dynamic iterators in the near future for code
decoupling and It would be a pity if these ranges couldn't fit in a
small object optimization buffer.

-- 
gpd