1. One of the first confusions that I naively had when I first approached the library was that classes that had close() methods did not necessarily model Closable. I am not sure if this means that “Closable” is a bad name and should be changed, but it might be worth calling out this distinction more pointedly in the documentation.
2. Perhaps for filtering streams, it would be best to make sure that closing the stream would close all the filters and flush the device. Would that solve this issue? Or is that already the current behavior?
   

The problem is that filtering_stream does not model Closable, so close()
is a no-op. This is counterintuitive and probably represent a less than
ideal design, but when I wrote the library I couldn't think of a
satisfactory way to define close() for a filtering stream.

You might think that the way to define close() would simply be to close
all the filters and devices in the chain. Unfortunately, this is not
correct. The reason is that while filters are designed to be reusable,
devices are in general one-use only. For example, when a compression
filter is closed, it is expected to be in a state where it can be used
to compress a fresh stream of data. But when a file is closed, it is not
reset to the state it was in when it was first opened: it has to be
manually reopened with a new user-provided pathname. So simply closing
all the filters and devices in the chain would leave the chain in an
unusable state.

The closest I could come to defining a non-trivial close() for
filtering_streams was to have close() call pop() -- in effect, closing
all the filters and discarding the final device. However, my feeling was
that this behavior would be considered counterintuitive.

I knew this could cause problems with copy, but I decided to wait for
user feedback before making any changes. The issue never came up, and I
forgot about it until now. It could be that not many are using the
library, as you suggest, or that people discovered that you can solve
the problem by calling reset() or pop() -- as you heard on the IRC
channel -- and never bothered to bring it up on this list.

I've created a ticket for this issue:
http://svn.boost.org/trac/boost/ticket/1624. At the very least it should
be a FAQ.

> Is anyone actually using the library? I can't believe I'm the first
> finding a bug like this in a 5 year old library.
>
>  S.


--
Jonathan Turkanis
CodeRage
http://www.coderage.com