Code review

[joto]

I looked at the code and have some comments:

1. https://github.com/mapbox/gzip-hpp/blob/master/include/gzip/compress.hpp#L27 That's confusing: The output parameter is of type InputType? And I would have expected the output parameter to come after the input parameters. But that's historically inconsistent in C APIs anyway...
2. Not sure we need the Compressor and Decompressor classes. The only thing that ever happens to them is that they are instantiated and then the (de)compress function is called on them. That would work as a simple function? I can see why this might be useful when we (de)compress in blocks, but the library can't do that due to the inflateInit2 and deflateInit2 functions not being in the constructor. Okay, we don't have to set those compression parameters every time, but how often do we re-use an instantiated Compressor or Decompressor object to make this useful?
3. Useless SECTION: https://github.com/mapbox/gzip-hpp/blob/master/test/test_io.cpp#L12
4. https://github.com/mapbox/gzip-hpp/blob/master/include/gzip/utils.hpp#L8 can be noexcept and the function is hard to follow due the many parentheses.
5. https://github.com/mapbox/gzip-hpp/blob/master/include/gzip/compress.hpp#L32-L38 Consider using assert() here.
6. There should be helper functions like (de)compress() that take an existing std::string and fill it.
7. https://github.com/mapbox/gzip-hpp/blob/master/include/gzip/decompress.hpp#L64 If the second condition is true, the first is also true, so this can be simplified.
8. https://github.com/mapbox/gzip-hpp/blob/master/include/gzip/decompress.hpp#L57 I don't think this is correct. If std::size is 32bit size * 2 will be 32bit and can overflow before it is assigned to the 64bit size_64. const auto size_64 = static_cast<uint64_t>(size) * 2; should be correct.
9. There are several places where inflateEnd is called (like here https://github.com/mapbox/gzip-hpp/blob/master/include/gzip/decompress.hpp#L60). Maybe this can be wrapped in an RAII wrapper somehow?
10. If we have gzipped-compressed data, the header can tell us how large the uncompressed data was. Can we use this to optimize this case and have the output buffer in the correct size from the beginning?
11. https://github.com/mapbox/gzip-hpp/blob/master/include/gzip/decompress.hpp#L55-L63 this can be moved above the inflateInit2 call saving an inflateEnd. Also consider making this an assert.

[springmeyer]

1. Nice catch, that is my typo
2. The motivation would be to make it possible to store something that is expensive to create once. By allowing this it would set us up to be able to have gzip-hpp consumers support an API change like Libdeflate port #25. But I admit this was perhaps engineering for the future probably too much.
3. nice catch
4. nice catch
5. 👍
6. we have some helpful functions like this but removed them due to confusing bugs from implicit conversion (Update Readme #1 (comment)). But I think those issues might have been based on a mis-understanding or a slightly different API, so introducing could be fine
7. nice catch
8. nice catch
9. or just cleaned up to avoid multiple calls, perhaps
10. I was under the impression that we cannot predictably know how large the uncompressed data is per Avoid re-allocation overhead by predicting the uncompressed buffer size? #11. Or maybe we should re-visit?
11. nice catch

@GretaCB you want to tackle making these changes? /cc @alliecrevier

[joto]

re 10: It might still be possible to make an educated guess. Most gzip files are not concatenated and most are not huge, so in most cases the number could be correct. Maybe it would also make sense to allow setting an "expected compression ratio" or something like it, if the client of the library knows that the stuff it is decompressing usually has a certain compression ratio.

Anyway, thats all optimizations that should probably only be considered if we have data to back it up, ie how often do we need to resize a buffer and how long does that take. Need to benchmark with real data.