chaining ouput iterator to input iterator

Hi,
I have a function that transforms a serie of numbers into another serie:
template

In this particular case, you can use boost::transform_iterator rather than std::transform, as Jeff pointed out. However, this does not resolve the problem in general, which is how to treat the sequence of values a function writes to an output iterator as a range (or pair of iterators) input to another function (without accumulating the elements in a container, of course). This seems like a textbook use case for coroutines. I wonder whether a solution using Boost.Context would impose sufficiently little overhead to provide a general solution to this problem. Regards, Nate

I'm not too sure how to call the transform_iterator in this case. I have these 2 functions that I need to provide separately because they are used separately. And I also need a 3rd function, called double stddev_of_transformed(InputIterator begin, InputIterator end) { return mytransform(begin, end, boost::transform_iterator( ... ) ); // ???? }
I'll take a look at this too, thanks, MM

Sorry, I thought by transform() you meant std::transform(). If you have your own mytransform() function (and you can't replace it with a call to std::transform()), then boost::transform_iterator may not be applicable. In that case, your options are 1) accumulate the outputs in a container in between the two calls, or 2) use a Boost.Context-based solution as I mentioned before. Regards, Nate

On Sun, Jul 8, 2012 at 5:33 PM, MM
Boost.Coroutine? Is that in boost vault?
Heh. There is a Boost.Coroutine in the Vault, but you're better advised to use the new Boost.Coroutine just coming up for review this week (I believe). IMO, either would be better than directly using Boost.Context. Context is a low-level library intended for use by application-level libraries such as Coroutine. It's just that any application-level library based on user-space context switching necessarily deals with the same platform-dependent issues; Oliver Kowalke has very usefully abstracted those out as Context. Now Oliver has presented us with a reimplementation of the original Boost.Coroutine prototype (in the Vault), based on his Context library. If you're willing, it would be very timely to add your opinion to the review about to be announced.

Presumably the doc is in the boost vault. I'll take a look Frankly, the coroutine seems very unnatural as I am accustomed to the separation of concerns, and the mechanism of of function call, and so on... I was also wondering if some lazy function from phoenix could help with this, or really a boost::transform_iterator could do it somehow MM

You're right, I was thinking of an earlier version of Boost.Context that had a high-level interface with an object of type 'context' which could be suspended/resumed etc. It seems this interface is not included in the Boost.Context that's currently in trunk and instead the functionality was moved to Boost.Coroutine? I totally missed that... Regards, Nate
participants (4)
-
Jeffrey Lee Hellrung, Jr.
-
MM
-
Nat Linden
-
Nathan Ridge