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 <[email protected]>: > 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:[email protected]] *Im > Auftrag von *Harald Achitz > *Gesendet:* Donnerstag, 24. Mai 2018 10:33 > *An:* ZeroMQ development list <[email protected]> > *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, <[email protected]> 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:[email protected]] *Im > Auftrag von *Harald Achitz > *Gesendet:* Donnerstag, 24. Mai 2018 09:40 > > > *An:* ZeroMQ development list <[email protected]> > *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, <[email protected]> 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:[email protected]] *Im > Auftrag von *Ernest Zed > *Gesendet:* Donnerstag, 24. Mai 2018 06:36 > > > *An:* ZeroMQ development list <[email protected]> > *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 <[email protected]> > 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, <[email protected]> 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: [email protected] > > 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 > [email protected] > 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 > [email protected] > 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 > [email protected] > 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 > [email protected] > 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 > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
