[Iterator] Interest in bzip2 compress/decompress iterators
I've written them for a work project. It would need to be essentially rewritten for Boost (different coding standards), but I'm willing to do it if there's interest and it would likely be accepted. It would depend on bzlib (part of bzip2) being installed. I noticed there's a gzip iostream, but no gzip iterator. This is a kind of precedent for the external dependency aspect. I've also written a class which produces a tar file in a streaming fashion to an output iterator. File contents are streamed in from input iterators. I'm not sure if this is useful or where it would go.
I haven't tried it, but what would prevent one from using
std::istreambuf_iterator and std::ostreambuf_iterator on an gzip/bzip2
filtering streambuf created with boost.iostreams?
On Mon, Dec 28, 2009 at 5:05 PM, Jason Felice
I noticed there's a gzip iostream, but no gzip iterator. This is a kind of precedent for the external dependency aspect.
2009/12/28 Boris Dušek
I haven't tried it, but what would prevent one from using std::istreambuf_iterator and std::ostreambuf_iterator on an gzip/bzip2 filtering streambuf created with boost.iostreams?
On Mon, Dec 28, 2009 at 5:05 PM, Jason Felice
wrote: I noticed there's a gzip iostream, but no gzip iterator. This is a kind of precedent for the external dependency aspect.
First, I didn't see that there was a bzip2 filtering streambuf, though
that might be because this code is currently stuck on boost 1.34.1
(for at least the next couple months).
Second, I've not used the filtering streambufs, but I assumed they
must decorate another streambuf. Seems a lot of extra machinery for
what I was doing. I was very happy about my solution being very well
abstracted such that the unit tests verified this stuff without
hitting the disk. I used back_inserter
participants (2)
-
Boris Dušek
-
Jason Felice