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

Thu May 24 10:33:21 CEST 2018

Hi Simon

I am on mobile so a bit restricted. But in short.

ad testing, if gtest is used it should be an installed libary, but google
has forgotten what ABI compatility is so they recommand downloading and
adding and rebuilding gtest into the project you use.
scaling this to my work this would mean >100 times download and rebuild for
nothing, google does not care about build times, this is a solved problem
(original zitat Titus Winters)
but I have to care.

alternative:
https://github.com/onqtam/doctest
just add the header, now download from the interenet required
if you want to know how to accelerate testing with doctest, I have written
about that recently
https://a4z.bitbucket.io/blog/2018/05/17/Speed-up-your-test-cycles-with-CMake.html

east const, for exampel row 165 and the code below
zmq_pollitem_t const *items
instead of
const zmq_pollitem_t * items
this is a  nerdy, and also funny, discussion in the C++ cummunity, but I
also find it unproductive.
Stroustrup / Sutter and co have stated their opinion in the CppCore
guildelines
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rl-const

pre C++11, somewhen needs to be the cut.
make a branch, put the old version there, forget it

I hope this gives you a bit more info and helps.

Regards,
Harald (now with pain in the fingers:-)

On Thu, 24 May 2018 at 10:10, <Simon.Giesecke at btc-ag.com> wrote:

> Hi Harald,
>
>
>
> thanks for your mail. Unfortunately, I fear you need to elaborate a bit
> more on your points so that I understand them.
>
>
>
>    - It seems google is infecting anyone with it’s monolithic build
>    philosophy.
>
> Too sad that you decided to fetch gtest.
>
>
>
> What do you mean by “monolithic build philosophy”? What problems do you
> see here? Which test framework would you have used? Do you think it is
> worthwhile to migrate?
>
>
>
> Note that for “building” cppzmq without tests, nothing should have changed
> (actually, there is nothing to build since it is header-only).
>
>
>
>    - Going east const might feel some more enlightened than others. But
>    now the file has 2 styles.
>
>
>
> Sorry, but I totally don’t get what you mean with this remark. Can you
> explain this?
>
>
>
>    - I also think that pre C++ 11 Support pollutes the code. It doesn’t
>    provide the same interface and functionality anyway. So why care?
>
>
>
> The addition of parts that require C++11 support started before I got into
> contact with cppzmq. I also think that it would be cleaner to use the same
> standard version everywhere, but I don’t want to break existing users.
> That’s why I asked if there are users that still require pre-C++11 support.
>
>
>
> Best regards
>
> Simon
>
>
>
> *Von:* zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] *Im
> Auftrag von *Harald Achitz
> *Gesendet:* Donnerstag, 24. Mai 2018 09:40
>
>
> *An:* ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> *Betreff:* Re: [zeromq-dev] cppzmq revival and RFC on design goals and
> supported platforms
>
>
>
> Some critics, hope this is ok.
>
>
>
> It seems google is infecting anyone with it’s monolithic build philosophy.
>
> Too sad that you decided to fetch gtest.
>
>
>
> Going east const might feel some more enlightened than others. But now the
> file has 2 styles.
>
>
>
> I also think that pre C++ 11 Support pollutes the code. It doesn’t provide
> the same interface and functionality anyway. So why care?
>
>
>
> I appreciate your efforts and I am happy that someone takes care about
> this.
>
>
>
> But it also seems to be the right time to focus on a own adopted version
> of this header.
>
>
>
> Regards
>
> Harald
>
>
>
> On Thu, 24 May 2018 at 09:13, <Simon.Giesecke at btc-ag.com> wrote:
>
> Hi Ernest,
>
>
>
> thanks for your mail!
>
>
>
> I am not sure if I get exactly what you want to achieve by detaching.
> Maybe open an issue on github with some code sketch of how you would use
> that, and/or a PR that implements it? I am not sure what kind of “hack” you
> refer to. If it is something that could be easily misused, it might be
> better not to include it.
>
>
>
> Regarding your second question, well, the community is in charge ;) I
> personally am not working on the zguide. If you would like to improve that,
> it would be very welcome.
>
>
>
> Best wishes
>
> Simon
>
>
>
> *Von:* zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] *Im
> Auftrag von *Ernest Zed
> *Gesendet:* Donnerstag, 24. Mai 2018 06:36
>
>
> *An:* ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> *Betreff:* 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 <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
> <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapi.zeromq.org&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7C90d876b632924bc4519b08d5c12feb4f%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627333917558531&sdata=JrTOCmytDVgVHiCOffOAv3pQ6I%2BWOJ7hVeiefD0CjQw%3D&reserved=0>
> 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
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzeromq%2Fcppzmq&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7C90d876b632924bc4519b08d5c12feb4f%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627333917558531&sdata=31MtvPSLH6oBgRyHbkUQOeRCF1hAWBbqjK%2F31hFzutk%3D&reserved=0>),
> 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
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzeromq%2Fcppzmq%2Fblob%2Fmaster%2FREADME.md&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7C90d876b632924bc4519b08d5c12feb4f%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627333917558531&sdata=JuSiHQECJNykVjawgnuhXl6%2FYl6BYiuUDp6lksqEqyc%3D&reserved=0>
> 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
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.zeromq.org%2Fmailman%2Flistinfo%2Fzeromq-dev&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7C90d876b632924bc4519b08d5c12feb4f%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627333917558531&sdata=krDx3Oxa5X3cOdIjY7SapwP2jkDRjtOjmbybsYnhkCA%3D&reserved=0>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.zeromq.org%2Fmailman%2Flistinfo%2Fzeromq-dev&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7C90d876b632924bc4519b08d5c12feb4f%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627333917714776&sdata=5aDm6Y6OCvXfIywP8jozDgBReWdTwxG%2BPJWIYU84ri4%3D&reserved=0>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.zeromq.org%2Fmailman%2Flistinfo%2Fzeromq-dev&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7Ccaee78efa4e34195850f08d5c149a74d%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627444456244154&sdata=lsglpxnyjw5Zw3WWsCl7WQzQBQi3WhKtvkdhG15adk0%3D&reserved=0>
>
> _______________________________________________
> 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/8fd21e02/attachment.htm>