<div dir="ltr">In the general case, yes, of course type isn't a runtime concern. However, it's a common scenario that a given topology may only expect one type (or format) to flow through it. In this case, type safety is a valuable sanity check and its absence is curious.<div class="gmail_extra">
<br><div class="gmail_quote">On Fri, Nov 15, 2013 at 2:26 AM, Daniel Krikun <span dir="ltr"><<a href="mailto:dkrikun0@gmail.com" target="_blank">dkrikun0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">ZeroMQ knows to transport just binary blobs, which helps keeping things simple and interoperable.<br>
As you say, it is indeed possible to send a zmq message which payload is an address in the memory (absolutely fine as long as it is in a single address space, i.e single process).<br>
However, in general case, type in c++ is completely a compile-time entity, and thus it can not be send in a zmq message.<br>
You can use some runtime type representation, for example, std::type_info, or design one of your own,  but you will have to add code to parse it and create variables of a type corresponding to this runtime representation.</p>


<div class="gmail_quote"><div><div class="h5">On Nov 14, 2013 10:49 PM, "Lindley French" <<a href="mailto:lindleyf@gmail.com" target="_blank">lindleyf@gmail.com</a>> wrote:<br type="attribution"></div></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div dir="ltr"><div><div>I'm investigating ZeroMQ for the first time, and I like the look of it overall. (It makes me realize I reinvented a portion of it unnecessarily about a year ago.)<br><br></div><div>I have some questions about the way inproc works. At first it looked great to me----all the benefits of QT signals and slots (unlike most signal/slot libraries, in QT slots can be defined to always run in a specified thread regardless of where the signal happened), but with all the other ZeroMQ patterns as well, not just pub/sub.<br>


</div><div><br></div>I do have one hesitation, though. At first, it seemed like it's requiring you to serialize data unnecessarily since messages are just blobs. This is probably not true; it appears you can just pass a pointer to an object. So long as there's no memcpy() of any kind happening under the hood (which is torture on some C++ objects), it's probably "fine". However, it still throws away type information, which is undesirable.<br>


<br></div>Has there been any effort to design a wrapper on top of inproc zeromq to make it type-safe?<br></div>
<br></div></div>_______________________________________________<br>
zeromq-dev mailing list<br>
<a href="mailto:zeromq-dev@lists.zeromq.org" target="_blank">zeromq-dev@lists.zeromq.org</a><br>
<a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
<br></blockquote></div>
<br>_______________________________________________<br>
zeromq-dev mailing list<br>
<a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>
<a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
<br></blockquote></div><br></div></div>