[zeromq-dev] C++ interface

Martin Sustrik sustrik at 250bpm.com
Tue Jan 19 11:41:04 CET 2010

Hi Asko,

> I worked on this today - mostly learning the details of the man pages.
> I'm not asking for this to be included, but maybe you want to have a 
> look. The C++ interface as now can be improved essentially, imho.

Changing the API is the most sensitive topic around. It affects 
basically everyone so we have to be careful here before moving any 
changes upstream.

*   - better error messages

The improvement we can introduce straight ahead IMO is adding throw 
specifications to individual functions. It improves the code and at the 
same time there are no backward compatibility issues.

*   - enums instead of flag ints

The problem here are name collisions. Stripping off the ZMQ prefix 
leaves us with constants such as "rate", "swap" or "sub" which are 
likely to collide with identifiers defined elsewhere (with "using 
namespace zmq"). It's also worth looking at other language bindings. 
Ideal solution would preserve the syntax accross the languages while 
still keeping namespacing stuff clear.

*   - set methods instead of use of enums or ints

Set methods would mean adding new code to each language binding each 
time new socket option is introduced. That's extremely hard to manage as 
there's no single person to understand _all_ the language bindings. Thus 
  adding new socket option would turn into major managerial task.

*   - use of 'zmq::pollitem' instead of C 'zmq_pollitem_t' (more 
covering up C details)

There's following line in the current trunk:

namespace zmq {
     typedef zmq_pollitem_t pollitem_t;

*   - error handling for 'zmq::poll()' (was missing!!)


*   - added 'const' to methods not changing the object

That can make sense at particular points (let's discuss them one by 
one), but in overall the semantics of const/non-const-ness in 0MQ is 
more complex than what C++ "const" technique is able to describe. For 
example, when copying a message (zmq_msg_copy) the content of the 
message is shared by 2 zmq::message_t instances. Thus, modification to 
non-const object may cause const object to be modified. Etc.

*   - 'zmq::socket_t' changed to 'zmq::socket' (and particular variants)

That would break backward compatibility without any particular reason.

* Note:
*   - using 'inline' is unnecessary if the body of the function is there:

Omitting the inline keyword used to cause problems with old versions of 
MSVC IIRC. It's harmless anyway so let's rather keep it in.

Can you please state that your patch is submitted under MIT license, so 
that I can push bits of it upstream?


More information about the zeromq-dev mailing list