Boost logo

Boost Users :

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

>>"eg" <egoots_at_[hidden]> wrote in message
>>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
>Could it be related to:
>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

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.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at