On Wed, Jan 25, 2012 at 8:15 PM, john skaller <[email protected] > 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)
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
