[zeromq-dev] [zmqpp] receiving can only be done to empty messages?

Lindley French lindleyf at gmail.com
Wed Jan 8 21:42:16 CET 2014


A question about the implementation.

I notice that the zmqpp::message_t class jumps through some hoops whenever
the add() or raw_new_msg() method is called. It appears to be creating a
new array of parts, moving all existing parts there, and then swapping them.

What's the rationale for this design? It seems like it would require a lot
more allocations and copies (thankfully only of pointers, not entire
buffers) than simply doing a push_back on the vector.


On Wed, Jan 8, 2014 at 2:01 PM, Lindley French <lindleyf at gmail.com> wrote:

> One additional minor suggestion: In the poller class, the add() and
> remove() overloads that take simple ints should probably accept them by
> value rather than const reference. There's no performance penalty, and it
> would make the type system play a bit nicer in some cases.
>
> For instance, I just tried to add a Boost.Asio UDP socket's
> native_handle() to a zmqpp poller (as a standin until UDP is working in
> 0MQ), and found that I couldn't do it if I was calling native_handle() from
> a const reference, but it worked fine with a non-const reference.
>
>
> On Wed, Jan 8, 2014 at 5:59 AM, Ben Gray <ben at benjamg.com> wrote:
>
>> Pull request https://github.com/zeromq/zmqpp/pull/29 raised for this
>> part of the issue (and the assert).
>>
>>
>> On 7 January 2014 16:24, Lindley French <lindleyf at gmail.com> wrote:
>>
>>>  In zmqpp, the socket_t::receive() method throws an exception if you
>>> pass it a non-empty message_t. This seems to be contradictory to the
>>> philosophy of zmq_recv(), which states that the message passed to it will
>>> be deallocated cleanly if necessary.
>>>
>>> Now, I know zmqpp defines a "message" as all parts of a multipart
>>> message, while libzmq defines it as just one part. So this isn't a direct
>>> contradiction of the API semantics. But it seems like this could be fixed
>>> without much effort.
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140108/9be4ea0d/attachment.htm>


More information about the zeromq-dev mailing list