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

Fri May 25 15:45:59 CEST 2018

Hi Simon,

thanks for reading my feedback and taking my thoughts into account!

yes, if the decision to use doctest is done I can help migrate tests and
will happily do this.
we could just add the header, migrate one test after an other over a while,
and than remove google test.
than this will not cause stress, I mean, it summer, here we had a long
winter here, it can be done smoothly :-)

please consider ping me direct when this is the case, it might be that I
miss some messages on this mailing list.

Regards,
Harald

Am Fr., 25. Mai 2018 um 09:41 Uhr schrieb <Simon.Giesecke at btc-ag.com>:

> Hi Harald,
>
>
>
> * test framework:
>
>
>
> Personally I have no particular preference for googletest, and at first
> sight I think we could go with doctest as well. I agree that not needing a
> build step is a plus, in particular for a project like cppzmq, which is a
> header-only library itself. However, someone would need to migrate the
> existing tests. Would you be willing to do that? That would be great. Maybe
> we should first seek if someone else has a particular preference for
> googletest or against doctest, which should be taken into account.
>
>
>
> * const:
>
>
>
> Thanks for making this clear, now I understand. I am aware of the
> discussion, but was not aware of the catchphrase "east const". I agree this
> should be done consistently. I had a lot of discussions about this in the
> past as well, and I think there is no reason to diverge from the
> recommendation in the C++ Core Guidelines (which means “west const”, right?
> ;) ). We should start some coding conventions, which need not be
> comprehensive, but list anything that was subject to debate, like this.
>
>
>
> Best regards
>
> Simon
>
>
>
> *Von:* zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] *Im
> Auftrag von *Harald Achitz
> *Gesendet:* Donnerstag, 24. Mai 2018 10:33
> *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 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
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fonqtam%2Fdoctest&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7C2916f028766c46380f1f08d5c1510f2d%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C1%7C636627476260537915&sdata=XiZoDgchvi7RXRP9HTnNtXuA9gsR4RLFgUGp4nNWXTQ%3D&reserved=0>
>
> 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
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa4z.bitbucket.io%2Fblog%2F2018%2F05%2F17%2FSpeed-up-your-test-cycles-with-CMake.html&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7C2916f028766c46380f1f08d5c1510f2d%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C1%7C636627476260537915&sdata=A476WGPWGDs%2Bx5727sTYwsc54E%2B4ynaXCiVlOZGIH%2Fo%3D&reserved=0>
>
>
>
> 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
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisocpp%2FCppCoreGuidelines%2Fblob%2Fmaster%2FCppCoreGuidelines.md%23Rl-const&data=02%7C01%7Csimon.giesecke%40btc-ag.com%7C2916f028766c46380f1f08d5c1510f2d%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C1%7C636627476260537915&sdata=oIUByoPyYSa6vwzRpG%2Bcyth3TPb6gzI%2Fze3eP5LVjBk%3D&reserved=0>
>
>
>
>
>
>
> 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
> <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%7C2916f028766c46380f1f08d5c1510f2d%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C1%7C636627476260537915&sdata=YSHs1VvABp3b5NErZ8M1ov1JS89QuL%2BUm7JN8f9WLwI%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/20180525/e88d1283/attachment.htm>