[zeromq-dev] (no subject)

[andrew S]

At first glance, having entirely separate classes for message_t and
const_message_t seems to be not a good idea. This model fits for
iterators, which are used in generic algorithms and may be of
arbitrary type. In user code, iterators are mainly used in loops (in a
single function) and not passed to other functions. Messages may be
stored in objects, passed to methods. With different types we either
would have to make all these functions/classes templates
(parameterized with MessageType) or explicitly/implicitly cast
message_t to const_message_t all the time. All this would clobber the
code.

But we could inherit message_t from const_message_t. The hierarchy
would be as following:
zmq_msg_t (private)
^
const_message_t
    (all const methods)
^
message_t
    (all modifiers)

Thus, we can pass message_t& to wherever const_message_t& is expected
(and not vice-versa). Const-correctness is naturally preserved.
It would be good to get some opinions about this model.

On Tue, Apr 26, 2011 at 1:54 AM, Pieter Hintjens <ph at imatix.com> wrote:
> 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
>>
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>