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

[Lindley French]

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/c82249f0/attachment.htm>