[zeromq-dev] more on c++ api

[Martin Sustrik]

Hi Burak,
> i got a few ideas that would be nice to have in the c++ api:
>
> 1) zmq.hpp has
>
> #include<assert.h>
> #include<string.h>
>
> in the beginning. converting them to
>
> #include<cassert>
> #include<cstring>
>
> would be better in line with c++ conventions, and in case of cstring
> header, would help keep the default namespace clean.
>    
Yes.

> 2) providing message_t (copy) constructors as such;
>
> message_t(const std::vector<uint8_t>  &) // for binary data
> message_t(const std::string&) // for strings
>
> will let us call socket.send("blah") or
> socket.send(vector_with_binary_data);
>    
The string constructor looks useful.

About vector<uint8_t> one I am not sure. I don't recall I've ever seen 
binary data stored in vector<uint8_t>. People tend to use raw malloc 
instead.

> 3) providing stream operators
>
> zmq::socket_t&operator<<(zmq::socket_t&, zmq::message_t&);
> zmq::socket_t&operator>>(zmq::socket_t&, zmq::message_t&);
>    
operator << normally has copy semantics, i.e. writing an object to a 
stream doesn't empty the object. zmq_send on the other hand has move 
semantics, ie. the message is emptied when sent. The move semantics 
could be in theory simulated using zmq_msg_copy, however, that would 
have performance impact.

My advise would be to wait till 0MQ/3.0 where standard POSIX-like 
zmq_send(void*,size_t) withe copy semantics will be available. Operator 
<< then can use that API.
> or even:
>
> std::ostream&operator<<(std::ostream&, zmq::message_t&);
>
> would be nice.
>
> 4) providing a multipart_message_t class and adding support for it to
> socket's relevant functions would make the api more elegant.
>    
Pretty hard to do that without introducing performance overhead 
(managing list of message parts within the multipart_message_t object 
and thus doing additional allocations). You can try though.
> i can probably work on those if you'd be willing to merge them before 3.x.
>
>    
Martin