Out of curiosity, why don't calls that take ownership also nullify a reference? For example, after a zmsg_push() the message owns the frame and will destroy it when the message is destroyed (zmsg_destroy(), zmsg_send()). Why doesn't this nullify the frame reference? (I personally just end up doing it myself the next line as it makes cleanup in case of errors easier for me.)
-Evan On Thu, Apr 18, 2013 at 8:03 AM, Michel Pelletier < [email protected]> wrote: > Ok, that makes perfect sense now, destroy is overwriting my pointer with > NULL so that I can check that. I'm using the picolisp "native" function > which is working well for all other czmq functions. It's not a problem > anymore, I'm faking it by wrapping my pointer in a one item structure and > passing a pointer to that. Almost have complete bindings! > > -Michel > > > On Wed, Apr 17, 2013 at 10:40 PM, Pieter Hintjens <[email protected]> wrote: > >> On Thu, Apr 18, 2013 at 7:17 AM, Michel Pelletier >> <[email protected]> wrote: >> >> > This is nagging me in a minor way: >> > >> > CZMQ_EXPORT zctx_t * >> > zctx_new (void); >> > >> > // Destroy context and all sockets in it, replaces zmq_term >> > CZMQ_EXPORT void >> > zctx_destroy (zctx_t **self_p); >> > >> > >> > Why does new return a pointer to a context, but destroy wants a pointer >> to >> > that pointer? I'm trying to call this functions via an FFI interface, >> but I >> > can't pass the result of new to destroy and I don't have the equivalent >> of >> > the & operator in the FFI environment. >> >> Hmm... the "destroy nullifies reference" pattern is one we've been >> using for sometime in C with success. I'd not realized it might create >> problems for bindings. >> >> > I've got a workaround, but is there a particular reason for this? >> >> The reason for the style is to clean up after destruction so that >> further code can catch null references and either ignore them or >> assert, but not try to access freed memory. That does work pretty >> well. All the CZMQ modules work like this. >> >> What are the limitations you have in FFI? >> >> -Pieter >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
