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

Subject: Re: [Boost-users] Limitations / Flaws with transformed_range
From: John M. Dlugosz (mpbecey7gu_at_[hidden])
Date: 2011-07-19 16:43:41

On 7/19/2011 3:41 AM, Nathan Ridge wrote:
>
> I don't think this "operator|" - which lives in the boost::range_detail
> namespace (note the "detail") - is meant to be specialized by users.

On the contrary.  It's not specialized, but overloaded, and the instructions say to do 
exactly that.  In particular, 
<http://www.boost.org/doc/libs/1_46_1/libs/range/doc/html/range/reference/extending/method_3/method_3_1.html> 
"Implement a Rage Adaptor without arguments".

>
> Why not accomplish this "massaging" through your own range adaptor instead?
>

The Range docs on is_literal explain that it's used inside an algorithm implementation, 
not explicitly by the caller.  I'm using my "prep" functions based on the nature of the 
argument, treating them in different ways.  The ability to deal with the argument in that 
way is a documented part of the algorithm.

The call to it is rather baroque rather than wrapped in another function that dispatches 
based on the tagging, because one of the differences from as_literal is that it doesn't 
always return the same type.  as_literal reforms whatever you gave it into a 
iterator_range.  src_prep only packs up primitive arrays and leaves other things 
_unchanged_.  The thought is that I can pass single-use ranges and not trigger them 
prematurely.  The simple-to-call wrapper would need another metafunction to form the 
return type, so I didn't bother.