ZeroMQ knows to transport just binary blobs, which helps keeping things simple and interoperable. 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). However, in general case, type in c++ is completely a compile-time entity, and thus it can not be send in a zmq message. 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. On Nov 14, 2013 10:49 PM, "Lindley French" <[email protected]> wrote:
> 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.) > > 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. > > 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. > > Has there been any effort to design a wrapper on top of inproc zeromq to > make it type-safe? > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
