Implementing Range Adaptor or "transformation" iterator
I see the documentation "doc/html/range/reference/extending/method_3/method_3_1.html" and want to do something like that. The Adaptor I want to write will transform the elements and provide a lazy transformed view. So, I need the return range to be a pair of transformed iterators, and a transform iterator works just like the underlying iterator only the * operator will apply my function to the value as it fetches it. But, it seems to me that there should be something like that already. Is there something I'm overlooking in STL or in some other Boost library? Thanks, —John
Date: Mon, 18 Jul 2011 18:43:57 -0500 From: mpbecey7gu@snkmail.com To: boost-users@lists.boost.org Subject: [Boost-users] Implementing Range Adaptor or "transformation" iterator
I see the documentation "doc/html/range/reference/extending/method_3/method_3_1.html" and want to do something like that. The Adaptor I want to write will transform the elements and provide a lazy transformed view.
So, I need the return range to be a pair of transformed iterators, and a transform iterator works just like the underlying iterator only the * operator will apply my function to the value as it fetches it.
But, it seems to me that there should be something like that already. Is there something I'm overlooking in STL or in some other Boost library?
There is something you are overlooking in the Boost.Range library itself :) http://www.boost.org/doc/libs/1_47_0/libs/range/doc/html/range/reference/ada... Regards, Nate.
On 7/18/2011 8:00 PM, Nathan Ridge wrote:
But, it seems to me that there should be something like that already. Is there something I'm overlooking in STL or in some other Boost library?
There is something you are overlooking in the Boost.Range library itself :)
http://www.boost.org/doc/libs/1_47_0/libs/range/doc/html/range/reference/ada...
Regards, Nate.
That's it, thanks. Hmm, but why is it producing a Single Pass Range? I would think it should naturally match the characteristics of the underlying Range.
On 7/18/2011 8:00 PM, Nathan Ridge wrote:
But, it seems to me that there should be something like that already. Is there something I'm overlooking in STL or in some other Boost library?
There is something you are overlooking in the Boost.Range library itself :)
http://www.boost.org/doc/libs/1_47_0/libs/range/doc/html/range/reference/ada...
That's it, thanks.
Hmm, but why is it producing a Single Pass Range? I would think it should naturally match the characteristics of the underlying Range.
Hmm... You're right, I see no reason why it needs to be a single pass range, and a quick look at boost/iterator/transform_iterator.hpp shows that transform_iterator (the iterator type wrapped by the range) does indeed leave alone the underlying iterator's traversal category. Perhaps it's just a mistake in the documentation? Regards, Nate.
The documentation says that Range Category: Single Pass Range This is a requirement of the input range. Range category of the output range is written as Returned Range Category: The range category of rng. So, if the input range is Random Access Range, then the output range is also Random Access Range. Regards, Michel
On 7/18/2011 10:28 PM, Michel MORIN wrote:
The documentation says that
Range Category: Single Pass Range
This is a requirement of the input range.
Range category of the output range is written as
Returned Range Category: The range category of rng.
So, if the input range is Random Access Range, then the output range is also Random Access Range.
I understand what you say. I looked at the page again, and the meaning is not clear as written. Perhaps it should be higher up, after "precondition" rather than among the return information, and say "Source Range" or something to balance the Range Return Type's qualification.
John M. Dlugosz wrote:
I looked at the page again, and the meaning is not clear as written. Perhaps it should be higher up, after "precondition" rather than among the return information, and say "Source Range" or something to balance the Range Return Type's qualification.
If you have such a suggestion or a request, I would recommend you to make a ticket at the trac (https://svn.boost.org/trac/boost/ ). Regards, Michel
participants (3)
-
John M. Dlugosz -
Michel MORIN -
Nathan Ridge