Boost C++ Libraries: Ticket #4728: "iostreams::detail::mode_adapter<>" is never "flushable": flushing a filtering_ostream will not flush the "std::ostream" target --- patch included.

attachment set

Tue, 12 Oct 2010 21:52:59 GMT

attachment → boost_iostreams-mode_adaptor-flushable.patch

Patch to fix boost::iostreams::detail::mode_adapter<> to be flushable when appropriate.

attachment set

Tue, 12 Oct 2010 21:53:46 GMT

attachment → boost_iostreams_filtering_std_ostream.cpp

Testcase to show that a filtering_ostream with a non-boost std::ostream device will not flush.

Steven Watanabe — Fri, 11 Feb 2011 15:31:09 GMT

I'm not convinced that stream should be flushed in this case.

Fri, 11 Feb 2011 16:40:51 GMT

Replying to steven_watanabe:

I'm not convinced that stream should be flushed in this case.

For clarity, do you mean that you're not convinced the stream should be flushed in the following case?

io::filtering_ostream out;
// Insert 0 or more calls to "out.push(SomeFlushableFilter())" here.
out.push(std::cout);
out << "a b c";
out.flush();

If so, can you give the reasons why not to flush? If not, then can you expand on which case you were talking about?

Here is why I think it should be flushed in the above case:

The programmer has asked for the stream to be flushed.
- Furthermore, std::ostream (thus, std::cout) has the capability of being flushed (it's "flushable"). That it doesn't explicitly have the flushable_tag is simply consequence of it being part of the STL.
  - See boost/iostreams/flush.hpp: boost::flush() will correctly flush std::ostream.
- In my opinion, the simplest interpretation of the API is that std::cout would be flushed in this case.
  - Why would the library flush std::ostream, but not a wrapper of std::ostream that is an implementation detail? (I previously assumed that this was an overlooked corner case, not an intentional behaviour. Was I wrong? What's the upside?)
  - Is there some other wrapper that the programmer could request use of? I'm thinking something like the following, that perhaps I missed in the documentation:
    out.push(boost::noignoreflush(std::cout));
    I maintain that it would be simpler if flushable objects were flushed by default. Something like the following could be used in the rare case that flushing requests should be ignored:
    out.push(boost::noflush(std::cout));
There isn't a technical challenge (unless my patch missed a corner case; I am not an expert).
When a stream is used as a communication channel with another process and timing matters (for example, if there is a handshake, deadlock is bad), not flushing in this case precludes the use of filtering_stream<> with a std::ostream sink.
- In my opinion, this is an unnecessary restriction on the use of filtering_stream<>.
- Another example: with the current behaviour, it is dangerous to use filtering_stream<> to add timestamps at the beginning of every line of program output. Even if the programmer reliably flushes the stream, the output cannot be viewed in real time.

boost@… — Fri, 21 Oct 2011 18:17:02 GMT

If this patch is not accepted, what is the canonical way of attaching cerr to a filtered stream so that it will flush properly. Is there a work around?

Fri, 21 Oct 2011 19:04:06 GMT

I couldn't find a workaround that did not use a patched header.

For my projects, I include a patched copy of mode_adaptor.hpp in an overlay (i.e., $MY_PROJECT/boost/iostreams/detail/adapter/mode_adapter.hpp). Since headers in $MY_PROJECT get precedence over system headers (i.e., I pass -I. to GCC), the patched version gets used automatically.

The bad news is that you need to maintain the patched version of mode_adaptor.hpp yourself when you upgrade Boost.

Wed, 09 May 2012 20:47:16 GMT

I happen to have exactly this problem. I applied the patch and it works for me. Could someone review it and reply, please?

Thanks.

cc set

Wed, 09 May 2012 20:47:59 GMT

cc boost-bugs@… added

version changed

Wed, 09 May 2012 20:48:53 GMT

version Boost 1.44.0 → Boost Development Trunk