From: Janson R. (mlists.aerostun_at_[hidden])
Date: 2020-03-09 20:56:09
On 09/03/2020 21:25, Domen Vrankar via Boost wrote:
> Now for the API of the library proposed by OP.
> I've skimmed over the code and allot of it seems like just-a-bit-above-C
> flavour - I could be wrong as I didn't find the examples and unit tests
> also haven't shown me how to easily use the library.
Observation is mostly correct, and it is one of the main reasons I've
come to ask for feedback here; Vinnie rightfully pointed out that the
question being asked is "what [does] a clean, Boost-quality, modern C++
API to codec that operates on memory buffers [look] like[?]".
Since the emails discussions have begun I've integrated the following
prototype API after suggestion by a few of the people here:
optional<std::string> easy_compress(string_view in, wrap wrapping =
optional<std::string> easy_uncompress(string_view in, wrap wrapping =
While it is definitely something that was needed (a friend of mine got
to use it and obviously found it much more trivial for his use than the
more expert-mode preexisting API), it definitely does not cover all the
possible use cases of such a library.
> What I'd like to see from a C++ library in general and Boost library in
> particular is a high quality API that would cover capabilities of
> libarchive (and use it as the underlying implementation at first). The APIs
> of primitives (inflate/deflate) should come at a later stage - perhaps not
> before C++ standardization of the APIs (and even then I'd expect that std
> libs would use what is already available in distro X instead of reinventing
> the wheel). My old lib has a poor API [...] but it's still a big simplification compared to
> libarchive C API and that's what I expect from a high quality wrapper -
> simplify allot but still let an advanced user squeeze the performance of
> the underlying implementation if/when needed (complexity should be reserved
> for those and hidden from us mere mortals).
Does that imply that you would welcome quality C++ wrappers for common C
libraries in the Boost ecosystem?
> For the capabilities of such API I'd expect it to work seamlessly with std
> streams (I don't care if people believe that they are slow, until they are
> part of the standard and there is no better std replacement I expect
> libraries of such type to work with them out of the box) and support for
> binary data not just std::string as in/out buffers in situations where you
> have everything already in memory or are using memory mapped files (perhaps
> also (Boost::)ASIO/Networking TS streams but that's your domain so you
> probably have a better opinion on how ASIO network payload could be
> compressed/decompressed on the fly).
That's exactly the kind of feedback and information I'm looking for; so
thanks! Possible quick function declarations are more than welcome to add!
> Regarding the OP's library as it currently stands I'd suggest integration
> of Boost::Beast instead (if it's a benefit) and split it into a separate
> library once it can serve as a high level Boost library's backbone (and get
> that high level API into Boost first).
Boost.Beast will need at some point at least some code being transferred
back into it to allow some HTTP features to be implemented (which are
the very first reason why I got on that adventure to begin with).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk