[zeromq-dev] zmq C++ wrapper

[Ilja Golshtein]

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

-- 
Best regards,
Ilja Golshtein.