> > 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. > > Another issue is object ownership -- who controls the life-time of the > object. In other words, when is it safe to deallocate the object? Keep > in mind, that ZeroMQ may drop messages if the high water mark is set. > > I agree this is an important concern. With a type-safe signals and slots library, you can just use a shared_ptr to take care of that. When you can't rely on type safety, you have to be a bit more clever. Probably you'd have to use placement new to construct a copy of the shared_ptr in the zeromq message, then placement delete on the other side to get rid of it after the receive occurs. That's the simplest way I can see to manage the reference count correctly.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
