[zeromq-dev] Language binding guidelines

Martin Sustrik sustrik at 250bpm.com
Tue Mar 2 10:34:31 CET 2010

Brian, Chris, Chuck,

>> Different style in naming.  I prefer to keep it more Rubyist.  If
>> create_socket is common in Python, it's perfectly good that way.
> I might end up going with "socket" as well depending on how others 
> like you go on this one.  I do think it is important to try to stay 
> somewhat close to the other bindings.

There was a good point raised by Martin Lucina yesterday, namely that 
all the unctions mimic the names used by C API, meaning that developer 
in whatever language can check C API documentation (man pages) with 
ease. create_socket would be the only exception, not mapping directly to 
zmq_socket. On the other hand, zmq_socket cannot be changed to 
zmq_create_socket as C API tries to mimic BSD socket API with its 
'socket' function.

>>>> 3. Ruby, like any GC based languages, needs explicit
>>>> close/term/disconnect methods for cleaning up resources used.
>>>> Even for C++, I'd argue that it's better to avoid relying on
>>>> destructor 100% for implicit resource cleanup.  It's especially
>>>> true in Java, the finalizer is not guaranteed to be called upon
>>>> process termination AFAIK and it's unpredictable when it'd get
>>>> called.  (Not saying that Java's finalizer is the same as C++
>>>> destructor.)
>>> But in a situation like 0MQ, it seems like the greater danger is
>>> to not perform the cleanup by forgetting to call the cleanup
>>> method. Thoughts?
>> It doesn't hurt to have the cleanup code in the destructor *also*,
>> but it shouldn't be the only place IMO.  One may choose to manage
>> the lifetime of the "socket" resource explicitly in C++.
> Yes, that makes sense.

C++ invokes destructors automatically and immediately. If you want to 
avoid strict scoping for the object you can allocate it dynamically:

     ctx = new zmq::context_t (1, 1);
     if (...)
         delete ctx; //  destructor is called here
} // instead of here

I prefer it this way as it doesn't require handling brain-dead objects.


More information about the zeromq-dev mailing list