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

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4728: "iostreams::detail::mode_adapter<>" is never "flushable": flushing a filtering_ostream will not flush the "std::ostream" target --- patch included.
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-02-11 16:40:51

#4728: "iostreams::detail::mode_adapter<>" is never "flushable": flushing a
filtering_ostream will not flush the "std::ostream" target --- patch
included.
---------------------------------------------------------------+------------
  Reporter:  Duncan Exon Smith <duncanphilipnorman@…>          |       Owner:  turkanis 
      Type:  Bugs                                              |      Status:  new      
 Milestone:  To Be Determined                                  |   Component:  iostreams
   Version:  Boost 1.44.0                                      |    Severity:  Problem  
Resolution:                                                    |    Keywords:           
---------------------------------------------------------------+------------

Comment (by Duncan Exon Smith <duncanphilipnorman@…>):

 Replying to [comment:1 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?
  {{{
 #!cpp
 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:
  1. 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:
    {{{
 #!cpp
 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:
    {{{
 #!cpp
 out.push(boost::noflush(std::cout));
 }}}
  1. There isn't a technical challenge (unless my patch missed a corner
 case; I am not an expert).
  1. 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/4728#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.