[zeromq-dev] (no subject)

[Matt Weinstein]

On Apr 21, 2011, at 4:49 PM, Martin Sustrik wrote:

> 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.
> 
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.

> 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);
> 
How about a new signature in the C case, e.g. zmq_msg_const_data()  ?  Something more consistent like zmq_msg_data_c() might be better, but then we'd have VMS :-)

> Thoughts?
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev