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

[Ben Gray]

The main reason for not just using push_back was that I was unsure how
shifting the message when vectors went over capacity would effect the
zmq_msg_t structures. I've since wrapped the whole lot in a frame object
that handles it and now does just use push_back. (see
https://github.com/benjamg/zmqpp/tree/feature/prepend_pop_message_frames)

This branch also has been switched to using a deque over a vector to
support push and pop front, however this appears to result in a much less
performant binding and so I need to take another look at it.

I may branch out the previous commit and issue a pull request for that
though as it would solve your need for a new_raw_msg with a size as well.


On 8 January 2014 20:42, Lindley French <lindleyf at gmail.com> wrote:

> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20140109/1beedb27/attachment.htm>