Re: [boost] lifetime of ranges vs. iterators

From: Arno Schödl (aschoedl_at_[hidden])
Date: 2008-09-02 17:39:51

> I'm trying to find out what the specific example applications are.  I
> have a suspicion that range adapters or single-level iterator adaptors
> may not be the best way to address these applications and may even
> sacrifice significant performance, but I can't tell until I know what
> the applications are.  Just so, single-level iterators (or ordinary
> range adapters, which don't add anything conceptually to iterators) are
> not the best way to address iteration over hierarchical data structures,
> which is why we have segmented iterators.

This is a typical one, copied straight from our code:

                grdlns->InsertGridlines( 
                        vecgvepsSource,
                        make_first_range(vecpairanchorsrcgrdln), 
                        GridlineInsertionPositions( 
                                make_transform_range(
                                        make_transform_range( 
                                                make_first_range( vecpairanchorsrcgrdln ),
                                                boost::mem_fn(&_vector< Ref<CGridlineAnchor> >::begin)
                                        ),
                                        boost::mem_fn( &CGridlineAnchor::Binding )
                                ), 
                                vecgrdlnSnapped),
                        vecgrdlnSnapped 
                );

This is a case in point: I did not write this code, and in the absence of specific guidelines against, the programmer decided to stack transform_range. In this case, performance-wise, this is no better or worse than using a single transform_range with boost::bind. Likewise, people may innocently write

rng | filtered( funcA ) 
    | filtered( funcB ) 
    | filtered( funcC ) 
    | filtered( funcD ) 
    | filtered( funcE )

blissfully unaware of any performance penalty.

> However, it seems to me that you already have a general answer in mind, 
> and it might be better to back up and look at the real problems you want 
> to solve before moving on to the answer.

Would it be my turn now to ask for some credit ;-) ? 

Arno

--
Dr. Arno Schoedl · aschoedl_at_[hidden] 
Technical Director 
 
think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany 
http://www.think-cell.com · phone [phone] · toll-free (US) [phone]
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229