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

[Harald Achitz]

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 :

> 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-boun...@lists.zeromq.org] *Im
> Auftrag von *Harald Achitz
> *Gesendet:* Donnerstag, 24. Mai 2018 10:33
> *An:* ZeroMQ development list 
> *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
> 
>
> 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,  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
> 

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

[Simon.Giesecke]

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-boun...@lists.zeromq.org] Im Auftrag von 
Harald Achitz
Gesendet: Donnerstag, 24. Mai 2018 10:33
An: ZeroMQ development list 
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
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, 
> 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

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

[Justus Ranvier]

I've been implementing a high level modern c++ wrapper for zeromq as part of 
the Open-Transactions project.

Our design goals probably differ from what you're doing with cppzmq, but some 
of the features we've added might be useful for an insipration or two.

* Seperation of interfaces from implementation and use of the Pimpl idiom to 
provide ABI compatibility
* Wrapper classes for libzmq types implement conversion operators so they can 
be passed directly to libzmq functions if needed
* Automatic creation of polling loops that pass received messages to lambdas 
provided at construction time
* Custom iterators for multipart messages that are compatible with ranged for 
loops. You can construct a ranged for loop over the routing frames, or over 
the messge body, or over every frame

Interface headers:
https://github.com/Open-Transactions/opentxs/tree/develop/include/opentxs/
network/zeromq

Implementation classes:
https://github.com/Open-Transactions/opentxs/tree/develop/src/network/zeromq


signature.asc
Description: This is a digitally signed message part.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

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

[Simon.Giesecke]

Hi Tomer,

did you use the current master version? 

Building cppzmq with cmakeworks with a non-cmake-built libzmq as well, this is 
also tested in the CI. As you can see in the CMakeList.txt file, it prefers a 
libzmq cmake package, but falls back to pkg-config if that is not found: 
https://github.com/zeromq/cppzmq/blob/1f14f9a34e23281bb88ed7e59ebd85c48542fa39/CMakeLists.txt#L9

If this doesn't work for you, please provide details of your setup, so we can 
resolve this.

This applies if you want to consume cppzmq as cmake package, otherwise you can 
simply use the header files as Luca already suggested.

Best regards
Simon

Von: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] Im Auftrag von 
Tomer Eliyahu
Gesendet: Donnerstag, 24. Mai 2018 13:40
An: ZeroMQ development list 
Betreff: Re: [zeromq-dev] cppzmq revival and RFC on design goals and supported 
platforms

I suggest to add support for building cppzmq without enforcing the build of 
libzmq via cmake. In openwrt for example, there is cmake support but zmq is 
built with autotools, which majes integrating cppzmq cumbersome so we 
eventually had to patch cppzmq to a previous version and strip some cmake 
features which were recently added. 

On Wed, May 23, 2018, 19:07  wrote:
Hi,

Pawel Kurdybacha (kurdybacha) and me (sigiesec) have recently started to 
"revive" cppzmq 
(https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzeromq%2Fcppzmq=02%7C01%7Csimon.giesecke%40btc-ag.com%7Cc0b516f851204eb3b25108d5c16b2999%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627588467547581=m62lXDj0U2uNMQkJN8gKn%2FARhJx5o%2Fl7%2BFO72FSP35A%3D=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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzeromq%2Fcppzmq%2Fblob%2Fmaster%2FREADME.md=02%7C01%7Csimon.giesecke%40btc-ag.com%7Cc0b516f851204eb3b25108d5c16b2999%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627588467547581=yQdG7mnHVVTgL0F8PGYUPl5%2BIObGn1X%2BLSXA0DKfQRQ%3D=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: mailto:simon.giese...@btc-ag.com

Rechtliche Hinweise: 
http://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
mailto:zeromq-dev@lists.zeromq.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.zeromq.org%2Fmailman%2Flistinfo%2Fzeromq-dev=02%7C01%7Csimon.giesecke%40btc-ag.com%7Cc0b516f851204eb3b25108d5c16b2999%7Cc064efb078954eebb406a40bc377bc7d%7C0%7C0%7C636627588467547581=%2BFngG0DTABbjDLt0Q8PGHo2sIcJndoH7db5OyJpDCGk%3D=0
___
zeromq-dev 

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

[Ernest Zed]

>> but I don’t want to break existing users

I have my two cents about more CPPish code. you dont have to break things
to make it more like modern c++, for starter it would be lovely to get rid
of these `#define`s and `typedef`s there.
and `typedef struct{} foo;` it is definitely not what you expect to see in
C++

Sincerely,
E.


On Thu, May 24, 2018 at 11:10 AM,  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-boun...@lists.zeromq.org] *Im
> Auftrag von *Harald Achitz
> *Gesendet:* Donnerstag, 24. Mai 2018 09:40
>
> *An:* ZeroMQ development list 
> *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,  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-boun...@lists.zeromq.org] *Im
> Auftrag von *Ernest Zed
> *Gesendet:* Donnerstag, 24. Mai 2018 06:36
>
>
> *An:* ZeroMQ development list 
> *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 
> 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 

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

[Ernest Zed]

Hi Simon,
I'm talking about the issue discussed here
https://lists.zeromq.org/pipermail/zeromq-dev/2012-February/015526.html ,
yep, a long time ago..

BTW, about owning pointers. The interface of functions which take a pointer
to a buffer, but does not own it, like:
`inline message_t(void *data_, size_t size_, free_fn *ffn_, void *hint_ =
NULL)`
What if the pointer to the data is managed anywhere else? like a pointer
from std::unique_ptr? in this case, definitely I dont want to
provide a deleter, because it is wrong to delete this pointer by any mean
except upon destruction of `unique_ptr` instance. So, I would end with a
piece of code like this:
`zmq::message_t msg(const_cast(data), size, [](void*, void*) {},
nullptr);`
Which is ugly as hell. Cant we just get a set of function which receive
non-owning pointers? Or an overload of existing functions with some king of
`tag` telling the message how to treat the pointer?

Sincerely,
Ernest



On Thu, May 24, 2018 at 10:14 AM,  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-boun...@lists.zeromq.org] *Im
> Auftrag von *Ernest Zed
> *Gesendet:* Donnerstag, 24. Mai 2018 06:36
> *An:* ZeroMQ development list 
> *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 
> 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.
>

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

[Luca Boccassi]

On Thu, 2018-05-24 at 14:40 +0300, Tomer Eliyahu wrote:
> I suggest to add support for building cppzmq without enforcing the
> build of
> libzmq via cmake. In openwrt for example, there is cmake support but
> zmq is
> built with autotools, which majes integrating cppzmq cumbersome so we
> eventually had to patch cppzmq to a previous version and strip some
> cmake
> features which were recently added.

You don't need to build it - it's just a header. Simply include it
wherever needed, which on *nix will be /usr/include/.

> On Wed, May 23, 2018, 19:07  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

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

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

[Tomer Eliyahu]

I suggest to add support for building cppzmq without enforcing the build of
libzmq via cmake. In openwrt for example, there is cmake support but zmq is
built with autotools, which majes integrating cppzmq cumbersome so we
eventually had to patch cppzmq to a previous version and strip some cmake
features which were recently added.

On Wed, May 23, 2018, 19:07  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

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

[Harald Achitz]

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,  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-boun...@lists.zeromq.org] *Im
> Auftrag von *Harald Achitz
> *Gesendet:* Donnerstag, 24. Mai 2018 09:40
>
>
> *An:* ZeroMQ development list 
> *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,  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-boun...@lists.zeromq.org] *Im
> Auftrag von *Ernest Zed
> *Gesendet:* Donnerstag, 24. Mai 2018 06:36
>
>
> *An:* ZeroMQ development list 
> *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,
>
> 

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

[Simon.Giesecke]

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-boun...@lists.zeromq.org] Im Auftrag von 
Harald Achitz
Gesendet: Donnerstag, 24. Mai 2018 09:40
An: ZeroMQ development list 
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, 
> 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-boun...@lists.zeromq.org]
 Im Auftrag von Ernest Zed
Gesendet: Donnerstag, 24. Mai 2018 06:36

An: ZeroMQ development list 
>
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 
> 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 

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

[Harald Achitz]

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,  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-boun...@lists.zeromq.org] *Im
> Auftrag von *Ernest Zed
> *Gesendet:* Donnerstag, 24. Mai 2018 06:36
>
>
> *An:* ZeroMQ development list 
> *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 
> 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
> 

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

[Simon.Giesecke]

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-boun...@lists.zeromq.org] Im Auftrag von 
Ernest Zed
Gesendet: Donnerstag, 24. Mai 2018 06:36
An: ZeroMQ development list 
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 
> 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 

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

[Simon.Giesecke]

Hi Gyorgy,

thanks for your mail!

Uniform sending could be implemented by providing a free send function which is 
overloaded for both message_t and multipart_t. There cannot be a member 
function of socket_t that accepts a multipart_t since the latter is in the 
upper layer (i.e. zmq_addon.hpp). If you would like to contribute this, this 
would be very welcome.

poller_t does not require casting a socket_t to the bare void * in the current 
master version. I am not sure when this was the case.

Best wishes
Simon

Von: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] Im Auftrag von 
Gyorgy Szekely
Gesendet: Mittwoch, 23. Mai 2018 21:10
An: ZeroMQ development list 
Betreff: 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. 

Re: [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 
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
>>
>
>
> ___
> 

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

[Gyorgy Szekely]

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] cppzmq revival and RFC on design goals and supported platforms

[Simon.Giesecke]

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