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 <p...@imatix.com> wrote: > On Thu, Apr 18, 2013 at 7:17 AM, Michel Pelletier > <pelletier.mic...@gmail.com> 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 > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
