[zeromq-dev] (no subject)

[Martin Sustrik]

On 04/21/2011 11:22 PM, Matt Weinstein wrote:

> IMHO in this context, "logically const" seems to allow for this asymmetry:
>
> 	copy is "logically const" (the details are irrelevant, you are not disturbing the underlying data)
> 	close is not "logically const" (you are disposing of a resource), it it were called zmq_msg_delete() it would be more obvious.

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.

What is really happening here is that we are using non-const descriptor 
pointing to const object.

In theory, const modifier on zmq_msg_t (the descriptor) can mean that 
the object (BLOB) itself is const while the descriptor is always 
non-const. However, I am not sure whether that doesn't mutilate C 
'const' semantics beyond the point of recognition.

Martin