Re: [Boost-users] boost::iostreams::copy() closes the sink andsource?

From: Ryan Melville (eng-list_at_[hidden])
Date: 2008-06-24 14:38:35

>>"eg" <egoots_at_[hidden]> wrote in message news:48613836.40003_at_gmail.com...
>>Melville, Ryan wrote: It seems that boost::iostreams::copy() closes its 
>>Source and Sink input parameters once it completes its copy.  This seems 
>>to be a problem for us because copy() is not the last thing we want to do 
>>with our Sinks; we copy() into them but then also put more stuff in them 
>>(which now fails).  This seems like a natural use case to me… Does anyone 
>>know why boost::iostreams::copy() feels the need to close the Source and 
>>Sink passed to it?  It seems to me that it should not.  The caller may or 
>>may not want them closed after the copy() and this behavior precludes 
>>using copy() as anything other than the last thing you want to do with a 
>>Sink.
>>
>
>Could it be related to:
>
>http://article.gmane.org/gmane.comp.lib.boost.user/33330
>
>which was addressed in:
>
>http://svn.boost.org/trac/boost/ticket/1624

Yes, it is kind of related.  Thanks for pointing those out because I hadn't 
seen them.

However, I think my issue is more about why close() closes its inputs at all 
as opposed to what affect a close() should have on the different types of 
inputs.

I'm missing why copy() should do any kind of close(), reset(), pop() or 
flush() at all.  It seems to be the Sink's business as to what happens to 
the data written into it, regardless of whether the data is written from 
copy() or something else.  I'm missing why it's necessary or even desireable 
to mandate a close of the Sink at the conclusion of the copy...

I guess I think I need a copy_no_close() variant.