[zeromq-dev] cppzmq revival and RFC on design goals and supported platforms

[Ernest Zed]

Hi,
It is a blessed move... so far, I'm missing few things, one of it, ability
to detach pointer from received message and pass ownership to another
object. I know it is not achievable by zmq, but there is a hack to
implement it.
Second, who is in charge of C++ examples? As I've reported before, the
Paranoid Pirate example doesnt work.

Sincerely,
Ernest

On Wed, May 23, 2018 at 10:09 PM, Gyorgy Szekely <hoditohod at gmail.com>
wrote:

> Hi Simon,
> This is great news! We're using cppzmq in a message broker and an
> accompanying communication library for 2 years now.
>
> I fully agree with the declared goals. libzmq has a simple and concise API
> with object oriented mindset. It works well on its own, but cppzmq makes it
> a whole lot easier. What's particularly good about it:
> - type safety and RAII: it's very straigtforward to think in classes that
> properly clean-up resources at destruction
> - higher level functions: multipart messages are really nice, though the
> API is/was a bit inconsistent (socket.send(msg) vs, msg.send(socket))
> - header only, it's very easy to use. Header only libraries usually mean
> template heavy monsters, but fortunately not in this case
>
> What I personally really like is it's a thin wrapper and doesn't want to
> be more than libzmq. Methods usually map 1-to-1 to libzmq calls, there's no
> hidden trickery and the documentation at api.zeromq.org is fully relevant.
>
> I haven't checked the recent updates (yet), but I found a few strange bits
> while working with cppzmq. Like the above mentioned sending inconsistency,
> or having to cast the socket to void* to use it in a pollset. Apart from
> that I completely agree with the direction. This is how a thin C++ wrapper
> should look like for a good base C API.
>
> BTW, we're using the lib on Ubuntu16.04 64bit / G++ 5.3, no issues so far.
>
> Regards,
>   Gyorgy
>
> On Wed, May 23, 2018 at 6:07 PM, <Simon.Giesecke at btc-ag.com> wrote:
>
>> Hi,
>>
>> Pawel Kurdybacha (kurdybacha) and me (sigiesec) have recently started to
>> "revive" cppzmq (https://github.com/zeromq/cppzmq), the light-weight C++
>> wrapper around libzmq. We added CI for Windows/MSVC, Linux and MacOS,
>> implemented tests, cleaned up the CMake infrastructure, formatted the
>> source code consistently and added some overview documentation.
>>
>> If you are using cppzmq or are interested in using it, we encourage you
>> to have a look at the recent changes.
>>
>> One particular point we would like to seek feedback on are the design
>> goals, which have recently been documented for the first time. I tried to
>> extrapolate them from the actual design, and from the reasons we chose to
>> use cppzmq in comparison to other alternatives. These are part of the
>> https://github.com/zeromq/cppzmq/blob/master/README.md file:
>>
>> * cppzmq maps the libzmq C API to C++ concepts. In particular:
>>    * it is type-safe (the libzmq C API exposes various class-like
>> concepts as void*)
>>    * it provides exception-based error handling (the libzmq C API
>> provides errno-based error handling)
>>    * it provides RAII-style classes that automate resource management
>> (the libzmq C API requires the user to take care to free resources
>> explicitly)
>> * cppzmq is a light-weight, header-only binding. You only need to include
>> the header file zmq.hpp (and maybe zmq_addon.hpp) to use it.
>> * zmq.hpp is meant to contain direct mappings of the abstractions
>> provided by the libzmq C API, while zmq_addon.hpp provides additional
>> higher-level abstractions.
>>
>> We would like to here from you if you agree with these design goals. If
>> you have any opposing views, proposals for improvement or extension of the
>> design goals, please share them on the mailing list or by sending a PR.
>>
>> Another part of the README is a section on the supported platforms.
>> Please review this section, in particular if you do not use MacOS, Linux or
>> Windows/MSVC with a recent compiler. If you successfully use a different
>> platform, please send a PR to include this in the list of "Additional
>> platforms that are known to work". Support for non-C++11 compilers is
>> already partial only, and might be removed completely, unless there are
>> users that still require such support.
>>
>> Of course, you are also invited to contribute extensions, new features,
>> cleanup, further tests, etc. to cppzmq.
>>
>> Best regards
>> Simon
>>
>> --
>> i.A. Simon Giesecke
>> BTC Business Technology Consulting AG
>> Kurfürstendamm 33
>> 10719 Berlin
>> E-Mail: Simon.Giesecke at btc-ag.com
>>
>> Rechtliche Hinweise:
>> www.btc-ag.com/impressum.htm
>> Handelsregister: Amtsgericht Oldenburg HRB 4717
>> Aufsichtsratsvorsitzender: Michael Heidkamp
>> Vorstand: Dr. Jörg Ritter, Dirk Thole
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180524/8f01bfa9/attachment.htm>