[zeromq-dev] zmq C++ wrapper

Emmanuel TAUREL taurel at esrf.fr
Wed Sep 7 12:57:11 CEST 2011


Hello all,

In the project I am actually workingon, I am using zmq.hpp over ZMQ 3.
I am also happy with it. It covers all my needs.

Just my 2 cents

Regards

Emmanuel Taurel

On 07/09/2011 12:40, Ilja Golshtein wrote:
> Pieter,
>
> to be honest I think zmq.hpp is not too bad.
> Why you are so much not happy with it?
>
> I don't treat our library as a 0mq C++ binding.
> It is mostly zmq_msg_t wrapper (that's why it is named zmqmessage,
> although I agree the name is not perfect, to put it mildly).
>
> I'll seriously consider your suggestions and do my best
> to transform our library to full featured C++ binding, despite
> the wish to publish the thing as soon as possible.
>
> Thanks.
>
>
>
> 07.09.2011, 14:09, "Pieter Hintjens"<ph at imatix.com>:
>> 2011/9/7 Ilja Golshtein<ilejncs at narod.ru>:
>>
>>>   Actually the idea of the code is to utilize powerful C++ features like streams, STL containers, templates, etc
>>>   to make 0mq a natural tool for advanced C++ development.
>>>   It is deeply C++ish.
>> Ilja,
>>
>> There is a C++ wrapper but I'd consider it immature and barely useful
>> over the low level C API. Some time ago we split it off as cppzmq,
>> with the intention of allowing others to take it and improve it. Its
>> current status is in between abandoned and green-field.
>>
>> Here is my advice, thus.
>>
>> First, do use the name cppzmq, we have a naming convention
>> (http://www.zeromq.org/docs:bindings) that avoids confusing names (and
>> zmqmessage is definitely confusing). If there are really two living
>> competing bindings, we number them and encourage the authors to merge
>> their work into one project.
>>
>> Second, do take the existing cppzmq, and extend it with your work.
>> Leave as much of the low level functionality as makes sense, and add
>> as much high-level functionality as you need to, without making it
>> excessive. Minimalism should be your tool.
>>
>> Third, do look at other high-level bindings such as erlzmq, pyzmq, and
>> czmq and see if you can reuse existing concepts and terminology. I've
>> found it extremely profitable for C development to have reactors,
>> thread management, etc. See
>> http://www.zeromq.org/topics:binding-abstractions. Take the
>> opportunity to support 0MQ/3.x and 0MQ/4.x while you're at it.
>>
>> There is a tension between accurately mapping the low level API to
>> language X, and adding functionality that really makes 0MQ shine in
>> that language. The successful bindings resolve this tension, but don't
>> run away from it.
>>
>> -Pieter





More information about the zeromq-dev mailing list