On Apr 22, 2011, at 2:05 AM, Pieter Hintjens wrote:
> On Fri, Apr 22, 2011 at 7:27 AM, Martin Sustrik <sust...@250bpm.com> wrote:
>
>> Ok. Another problem: Copy of a const message should be a const message.
>> Imagine this prototype:
>>
>> int zmq_msg_const_copy (const zmq_msg_t *dest, const zmq_msg_t *src);
>>
>> The message passed as 'dest' is closed (non-const operation), then
>> filled-in by the copy of the const message. Yet the parameter cannot be
>> both const and non-const at the same time.
>
This may be stretching the semantics a bit, but you could use the iterator
model, and have two zmq_msg types:
const_zmq_msg_t
zmq_msg_t
Then the intended semantics w/could be preserved (as well as the transforms).
Unfortunately, the name mangling may start getting out of control at this point
:-)
> Isn't the problem here that you're mixing two methods in one, i.e.
> 'delete and then copy into'?
>
> The side-effect of deleting any previous message is not nice,
> especially since the rest of the message API is so pedantic.
>
> If you made the copy semantics clean, the copy would be a const message.
>
> I also like the idea of renaming 'close' to something more sensible,
> delete (confusing IMO) or destroy (better).
>
Perhaps "release" might be better, since destroy / delete imply immediacy,
whereas release usually means GC (someday)....?
> -Pieter
> _______________________________________________
> 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
