[zeromq-dev] Any way to make inproc type-safe?
dkrikun0 at gmail.com
Fri Nov 15 08:26:55 CET 2013
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" <lindleyf at gmail.com> 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
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev