boost::iostreams::copy() closes the sink and source?
Hi, While upgrading from boost 1.34.1 to boost 1.35.0 we encountered an issue with boost::iostreams. 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. BTW, the apparent intended behavior of copy() is not different in this regard between 1.34.1 and 1.35.0. Rather, the trigger here was that our boost::iostreams::filtering_ostream derived classes are now "closable" by virtue of the "closable_tag" being added to the boost::iostreams::filtering_ostream base class' "categories". Once they became "closeable", copy()'s invocation of close() actually resulted in a close() on them instead of just a flush(). Any insight would be greatly appreciated. Unless I hear some rational for the current behavior I'm inclined to change copy() to not close its Source and Sink. For backwards compatibility, I suppose a "bool close = true" input parameter could be added. That would allow one to override the existing behavior without changing the current behavior on existing code. Although, it really doesn't seem natural to have something called "copy()" close its input parameters and I'm sure the unwary will get burned like us when subsequent uses of the Sink fail unexpectedly. Also, I'm not sure how this interacts with "const" inputs. The documentation implies that copy() also works with a const Source or const Sink, but I haven't tried that. It could not close a const Source or Sink, right? And it could not even write into a const Sink so I'm not sure what the purpose of that input combination would be. Regards, Ryan Ryan Melville Email: Office: Fax: Xiotech Corporation 6455 Flying Cloud Drive Eden Prairie, MN 55344 United States www.Xiotech.com <http://www.xiotech.com/> : Toll-Free 866 472 6764
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
"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.
participants (2)
-
eg -
Melville, Ryan -
Ryan Melville