Subject: Re: [boost] lifetime of ranges vs. iterators
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-03 14:39:50
On Wed, Sep 3, 2008 at 7:21 PM, David Abrahams <dave_at_[hidden]> wrote:
> on Wed Sep 03 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
>> Do you think we are breaking the iterator abstraction? How? Or I've
>> misunderstood the question?
> Well, if we add "Factorable" or something like it, the iterator
> abstraction gets broken down into smaller bits for the purpose of
> storage, complicating some code [like a generic range for example ;-)]
> and it imposes an extra coding duty on writers of high-quality iterator
> adaptors. I'm asking if its worth it.
>> We are simply trying to come up with a simple and clean trick to keep
>> iterator size under control.
> Really? IIUC so far we're only discussing compressing the size of
> ranges, unless we're willing to pay for indirection inside of iterators
> (I'm not).
But iterators like filter_iterator that need to know iteration
boundaries, can store a range instead of an iterator, so they can
benefit from the compression.
>>>> I'm interested in using dynamic iterators in the near future for code
>>> You mean, like, any_iterator?
>>>> and It would be a pity if these ranges couldn't fit in a small object
>>>> optimization buffer.
>>> Do you know how big that target ("small object optimization buffer") is?
>> I'm going to implement my own any_iterator, so I'll make the buffer
>> big enough for the average iterator size.
> Oh, that's not the small object optimization. The SOO is only done by
> compilers: it means passing small objects in registers instead of on the
> IIUC you're talking about the too-specifically-named "small string
Ah, ok, I also saw it begin called small buffer optimization. I
confused object with buffer.
> I don't understand why you would implement any_iterator yourself when
> there are so many extant implementations, but maybe it's none of my
Mostly for experimenting. I'll might end up using something third
party in real code.
>> Currently the iterators I use are often over 400 bytes, which is a bit
>> to big :), thus the need to squeeze their size down as much as
>> possible. A hundred bytes could be enough .
> Again, have you measured?
If you mean the size, yes, I've measured it. If you mean my assertion
that 100 byte SBO may be optimal, then I wont' let facts interfere
with my opinions :)
Now, honestly, I'm trying to rationalize the fear that I had for a
while that complex iterator adaptor sequences really can grow large.
For example, the current filter_iterator double its size at every
stacking. If you couple it with a relatively heavy predicate, the
stack usage might start to really matter. On heavy threaded
applications, stack usage is a somewhat limited resource.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk