[zeromq-dev] (no subject)

[Pieter Hintjens]

Ilja,

Thanks for the patch... I'd like to get some review from others on the
list before we apply this to the stable release.

-Pieter

2011/4/25 Ilja Golshtein <ilejncs at narod.ru>:
> Patch with (2), (4) and (5) against 0mq 2.1   43307455e352769189d427f260c4b48a3a19f7ce
> is attached.
>
> 22.04.2011, 23:29, "Ilja Golshtein" <ilejncs at narod.ru>:
>> Martin, All,
>>
>> you are right, there is no 100% similarity with std::string.
>>
>> Trying to look at the message_t from the same angle we should conclude:
>> 1. close() in not const regardless BLOB - it destroys message object. And there is no such a method by the way. Did you ever see const destructor?
>> 2. copy() is not a const method because it changes the object. Though argument of the method should be const message_t *msg_. Initially I was confused by copy semantic. If argument were marked as constant I would not!
>> 3. move() is not a const method and it's argument is not const*
>> 4. size() is undoubtedly const
>> 5. good idea to have const and non const data() methods. Absence of overloading at C level could be simply ignored.
>> 6. const_message_t  is logical from C++ standpoint, though I think it worth introducing if any performance gain is possible.
>>
>> Thanks.
>>
>> 22.04.2011, 00:49, "Martin Sustrik" <sustrik at 250bpm.com>;:
>>
>>>  Ilja, Andrew,
>>>
>>>  std::string is able to make the reference counting trasparent to the
>>>  user using CoW semantics. Unfortunately, with zmq_msg_t we don't have
>>>  this option.
>>>
>>>  The place where the abstraction leaks most is zmq_msg_close() function.
>>>  It removes one reference from the BLOB (const operation) and if it
>>>  reaches zero, it deletes the BLOB (non-const operation).
>>>
>>>  The most sensible option seems to be to treat close as non-const
>>>  operation. The ugly part is the asymmetricity between zmq_msg_copy()
>>>  which adds a reference and zmq_msg_close() which removes a reference.
>>>  Former is const operation while later is non-const operation.
>>>
>>>  Another problem is getting a const data pointer from const message
>>>  object. C doesn't support polymorphism so something like this is not
>>>  possible:
>>>
>>>       void *zmq_msg_data (zmq_msg_t *msg);
>>>       const void *zmq_msg_data (const zmq_msg_t *msg);
>>>
>>>  Thoughts?
>>>  Martin
>>>  _______________________________________________
>>>  zeromq-dev mailing list
>>>  zeromq-dev at lists.zeromq.org
>>>  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> --
>> Best regards,
>> Ilja Golshtein.
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> --
> Best regards,
> Ilja Golshtein.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>