Re: [zeromq-dev] cppzmq revival and RFC on design goals and supported platforms
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 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, 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.giese...@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@lists.zeromq.org >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org >
Re: [zeromq-dev] cppzmq revival and RFC on design goals and supported platforms
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, 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.giese...@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@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] zerocopy
Hi, New zerocopy in Linux 4.18, I remember Luca did something at the latest hackaton: https://lwn.net/Articles/752188/ Best, -- Benjamin Henrion (zoobab) Email: zoobab at gmail.com Mobile: +32-484-566109 Web: http://www.zoobab.com FFII.org Brussels "In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators." ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] cppzmq revival and RFC on design goals and supported platforms
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.giese...@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@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
