"eg" <egoots@gmail.com> wrote in message news:48613836.40003@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:
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.