search

stachenov / quazip

Qt/C++ wrapper over minizip
Other
563 stars 235 forks source link

Isolating raw ZLib API? #107

Open target-san opened 3 years ago

target-san commented 3 years ago

Hello!

Is raw ZLib API strictly necessary for using QuaZip? Can it be isolated somehow, to have clean Qt API? It's possible though that I'm using non-public headers, as some headers like quagzipfile.h, quaziodevice.h include <zlib.h> directly. The other peculiarity is that package installed by CMake requires ZLib as its dependency unconditionally, even if QuaZip was compiled as shared lib.

Thanks

stachenov commented 3 years ago

I think it's quite easy to get rid of #include <zlib.h> in those two headers. As far as I can see, these are pure headers with no inline functions or anything.

But the dependency itself would still be there. QuaZip is nothing more than a convenience wrapper around Minizip, and Minizip's API is exposed everywhere. It wasn't designed as a ZIP library with Minizip as an implementation detail, but rather than as an extension of Minizip. It was probably a design mistake, but now it can't be fixed until at least QuaZip 2.0. And that would require some time which I'm afraid I don't have.

And because Minizip itself uses zlib directly, the dependency is unavoidable. So the best I can do is to get rid of unnecessary zlib.h includes in some public headers. Minizip headers include it too, and they are considered public headers as well, so... it won't really help that much.

target-san commented 3 years ago

So, just in theory, if someone uses only Qt API, can he drop minizip and zlib headers? EDIT: It seems that zip.h and unzip.h depend on ZLIB API. And they're included in quazip.h. Not the best news :(

stachenov commented 3 years ago

It should be possible to get rid of those. I think Minizip API is only exposed through error codes, which are just ints. Everything else in theory could be moved to source files thank to the Pimpl idiom.