Re: [Boost-users] Limitations / Flaws with transformed_range

Subject: Re: [Boost-users] Limitations / Flaws with transformed_range
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2011-07-19 04:41:40

> I've found another issue, and I consider it a "flaw" because it is a Limitation due to
> oversight or an artificial restriction, and the deeper workings should handle these cases
> just fine. Let me explain in detail:
>
> The
> template< class F, class R >
> struct transformed_range :
>
> takes two arguments. The R argument is used for two purposes. It gives the iterator type
> that will be held, via range_iterator<R>::type. It also gives the exact type of the
> argument expected by the constructor.
>
> Now here is an example from my experiments / work-in-progress:
>
> template< class Range >
> inline transformed_range<ASCII_lower,const Range>
> operator|( const Range& r, const ASCII_lower_forwarder )
> {
> return transformed_range<ASCII_lower,const Range>(
> ASCII_lower(), // The underlying transform iterators wants this
> internal::src_prep(typename std::tr1::is_pointer<Range>::type() ,r) //
> "source" style argument processing
> );
> }
>
> The src_prep is similar to the supplied is_literal, and used for the same purpose. It
> will package a primitive array as a iterator_range, handing string literals and primitive
> array objects in the way I intend with respect to nul terminators. It differs from
> is_literal in several ways, but the idea is the same.
>
> Now I don't have to do anything to the Range parameter passed as the type argument to
> transformed_range, because even when I change the type of the massaged argument, it still
> has the same underlying iterator type. After all, it gets the iterators from the original
> range thing passed in.
>
> But, the massaged value of r is rejected by the constructor, because it has a different
> type. It doesn't need to be the same type! It has the same underlying iterator type and
> could be assigned to it, but the constructor is too strict.

I don't think this "operator|" - which lives in the boost::range_detail 
namespace (note the "detail") - is meant to be specialized by users.
 
Why not accomplish this "massaging" through your own range adaptor instead? 
 
As in:
 
my_range | my_massager | transformed(ASCII_lower())
 
If you use this a lot, you could write a range adaptor that combines the two:
 
my_range | ascii_lowered
 
 
Regards,
Nate.