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 <p...@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 <ilej...@narod.ru>:
>> Patch with (2), (4) and (5) against 0mq 2.1
>> 43307455e352769189d427f260c4b48a3a19f7ce
>> is attached.
>>
>> 22.04.2011, 23:29, "Ilja Golshtein" <ilej...@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" <sust...@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@lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> --
>>> Best regards,
>>> Ilja Golshtein.
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>> --
>> Best regards,
>> Ilja Golshtein.
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
