Re: [Boost-users] chaining ouput iterator to input iterator

Subject: Re: [Boost-users] chaining ouput iterator to input iterator
From: MM (finjulhich_at_[hidden])
Date: 2012-07-08 07:38:00

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Nathan Ridge
> Sent: 08 July 2012 06:18
> To: Boost Mailing List
> Subject: Re: [Boost-users] chaining ouput iterator to input iterator
> 
> 
> > I have a function that transforms a serie of numbers into another
> serie:
> >
> > template <typename InputIterator, typename OutputIterator>
> > void mytransform( InputIterator begin, InputIterator end,
> OutputIterator out )
> > {
> > }
> >
> >
> > and a 2nd function that calculates the standard deviation of a sample
> >
> > template <typename InputIterator >
> > double stdev( InputIterator begin, InputIterator end)
> > {
> > }
> >
> > Is there a way to chain these existing functions in order to get the
> std dev
> > of the transformed serie, without storing the intermediate numbers?
> > Maybe with the help of some lazy iterator, or some lazy function?
> 
> 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).

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( ... ) );  //
????
}

> 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.
> 
I'll take a look at this too,

thanks,
MM