Boost logo

Boost :

From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2020-03-06 15:51:21


On Fri, Mar 6, 2020 at 12:50 PM Janson R. via Boost
<boost_at_[hidden]> wrote:
> I have recently been working on a C++ compression library very similar
> to zlib after trying to implement some HTTP compression support over
> Boost.Beast and realizing after some discussion with sir Falco that
> while it would be a nice builtin feature for Beast, it would possibly be
> a better idea to have zlib-like compression be a separate library in
> order to be properly maintainable and likely more useful.

> Do you thing that this could be useful to have as its own entity in the
> Boost environment? Any kind of feedback on the idea and the library is
> warmly welcome.

(As someone who had to recently peek into the zlib C source code...)

Hi. I'd very much welcome a clean pure C++ implementation of basic
deflate compression,
because the C code I saw did not give me a warm and buzzy feeling, honestly.

I need access to ZIP files, and since minizip and zlib are pretty much
intertwined,
as far as I saw, I couldn't easily use this new library, if it lacked
ZIP support. And if
that support allowed efficient *and* multi-threaded access to the ZIP
entries, all the
better. The raw file IO can still be serial, but at the very least the
compression /
decompression should be able to run in parallel on multiple threads, via ASIO.

I'm dealing with ZIP files which reach into the 100,000s to millions of entries,
and having to serially read+uncompress or compress+write per entry is slow!
All those cores could be put to good use.

Lastly, a quick glance at the code showed plain enums vs enum classes,
capitalized vs all-lowercased enums; such naming inconsistencies was surprising.
Perhaps it's from "consistency" with zlib? Not sure it's a good idea.
Pick a style and
stick to it IMHO.

Thanks, --DD


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk