[zeromq-dev] Any way to make inproc type-safe?

[Lindley French]

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.

On Fri, Nov 15, 2013 at 2:26 AM, Daniel Krikun <dkrikun0 at gmail.com> wrote:

> 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
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131115/efa4fe57/attachment.htm>