[zeromq-dev] czmqpp
Yi Ding
yi.s.ding at gmail.com
Thu Jan 26 23:08:12 CET 2012
On Wed, Jan 25, 2012 at 8:15 PM, john skaller <skaller at users.sourceforge.net
> wrote:
>
> On 26/01/2012, at 6:26 AM, Yi Ding wrote:
>
> > I remember Martin or Pieter saying somewhere that zmq.hpp (cppzmq)
> wasn't really being maintained these days and wasn't super useful to begin
> with.
> >
> > It seems to me that czmq is a much more useful binding, and the only
> thing it really lacks for C++ programming is RAII.
>
> That's a good thing. RAII (except locally) is a very bad paradigm.
> In particular it does not play well with any kind of automated memory
> management,
> especially garbage collection***
>
> Local (on stack) RAII is ok (and perhaps even necessary do the presence
> of evil exceptions).
>
> ** All advanced systems are necessarily garbage collected, even if they're
> written
> in C or C++. That's because there is no other general strategy for managing
> graphs. Of course all advanced networking applications have graph
> topologies
> and involve external resources (sockets, nodes, OS stuff, even hardware).
>
> RAII in these circumstances is utterly evil. Don't go there.
> Management of the representative objects does NOT reflect the proper
> management of resources: the sequence of assembly and release
> of the representative and the actual resources not only may be distinct,
> it almost invariable is necessarily distinct.
>
> For example you may construct a topological representation of a network
> in some order, and then activate it node by node in a quite different
> order.
>
> If you have a look at ZMQ itself, which is written in C++, you'll note that
> the primary classes are not initialised by constructors, but separate
> init functions. After all .. a message, for example, can be initialised
> multiple times in its lifetime (I actually think this is a bit over the
> top,
> its very error prone .. I'm not allowing that in the Felix binding .. BUT
> it has one advantage: maximal efficiency).
>
> Strict RAII would be counterproductive in certain cases, I agree, but it's
not a big deal to have an init function in a class and still let that class
handle all of the allocated memory (and deallocate it when it goes out of
scope)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120126/b131e1af/attachment.htm>
More information about the zeromq-dev
mailing list