Boost logo

Boost Users :

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,
"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.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at