Re: [boost] [range] rationale for transform_range() algorithm?

From: Pavol Droba (droba_at_[hidden])
Date: 2005-03-14 02:29:40

Hi,

On Sun, Mar 13, 2005 at 10:04:05PM -0800, Eric Niebler wrote:
> 
> Background:
> 
> I have been working on range-based algorithms and adaptors. The 
> algorithms are variants of the std::algorithms that accept ranges 
> instead of a [begin,end) iterator pair. The adaptors are like the 
> iterator adaptors, except they adapt ranges.
> 
> Following the principal of least surprise, I want to call my range 
> adaptors filter_range, indirect_range, reverse_range and transform_range 
> (to parallel filter_iterator, indirect_iterator, etc). But I can't do 
> this, because there already is a transform_range, and it's a function!
> 
> Problem:
> 
> At the bottom of iterator_range.hpp is this:
> 
>    template< typename SeqT, typename Range, typename FuncT >
>    inline SeqT transform_range( const Range& r, FuncT Func )
>    {
>        SeqT Seq;
>        std::transform( begin( r ), end( r ),
>                        std::back_inserter(Seq), Func );
>        return Seq;
>    }
> 
> I'm not sure why. It looks like a range-based algorithm, but ... why 
> provide only one? (Two actually -- copy_range is there also.) And why 
> call it transform_range() instead of just calling it "transform" and 
> making it part of a complete range-based algorithm library?
> 
> Solution:
> 
> I suggest the functions copy_range() and transform_range() should be 
> removed or moved into a "deprecated" namespace, freeing up the 
> identifier "boost::transform_range" to be a type, analagous to 
> boost::transform_iterator. Development should proceed on a range-based 
> algorithms library to fill the need that the existing 
> "transform_range()" function is meeting.
> 
> Thoughts?
> 

Originaly I was the author of iterator_range class and the utilities.
It was then taken to Boost.Range library as a more meaningful place.

Rantionale for these two functions was to improve the usability of 
iterator_range class.

transform_range is not so crucial, but the copy_range is very important.
Without it you cannot easily convert iterator_range to a string for
instance. You need to go through iterator-constructor.

So instead of

str=copy_range<std::string>(aRange);

You need to write
str=std::string(aRange.begin(), aRange.end());

The second one is not as nice, but what is more important, it disallows
you to pass a range by value in a chain. In other words, you cannot
write 

str=copy_range<std::string>(find_first(input,"helo"));

To sumarize, copy_range is an essential utility, that provides a way of
copying between different range types, especialy the legacy ones like
std::string. Therefor it has an important place in the Boost.Range
library.

Regards,

Pavol