Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #4043
| Date | 2011-04-26 16:03 +0200 |
|---|---|
| From | Hegedüs Ervin <airween@gmail.com> |
| Subject | Re: Py_INCREF() incomprehension |
| References | <mailman.830.1303811297.9059.python-list@python.org> <ip6dc5$m7d$1@r03.glglgl.eu> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.839.1303826380.9059.python-list@python.org> (permalink) |
Hello,
thanks for the answer,
> >Everything works fine, but sorry for the recurrent question: where
> >should I use the Py_INCREF()/Py_DECREF() in code above?
>
> That depends on the functions which are called. It should be given
> in the API description. The same counts for the incoming parameters
> (which are borrowed AFAIR - but better have a look).
I've read API doc (which you've included in another mail), but
that's not clear for me. :(
> The most critical parts are indeed
>
> * the input parameters
>
> and
>
> * Py_BuildValue()
>
> . Maybe you could as well have a look at some example code.
>
> Especially look at the concepts called "borrowed reference" vs.
> "owned reference".
>
> And, for your other question:
>
> > if (cRes == 0) {
> > return Py_BuildValue("s", outdata);
> > }
>
> You ask how to stop leaking memory? Well, simply by not leaking it :-)
great! :)
> Just free the memory area:
>
> if (cRes == 0) {
> PyObject* ret = Py_BuildValue("s", outdata);
> free(outdata);
> return ret;
> }
so, it means when I implicit allocate a new object (whit
Py_BuildValue()), Python's GC will free that pointer when it
doesn't require anymore?
> BTW: Is there any reason for using calloc()? malloc() would probably
> be faster...
may be, I didn't measure it ever... but calloc() gives clear
space... :)
thanks:
a.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar
Py_INCREF() incomprehension Ervin Hegedüs <airween@gmail.com> - 2011-04-26 11:48 +0200
Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 14:23 +0200
Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 14:21 +0200
Re: Py_INCREF() incomprehension Hegedüs Ervin <airween@gmail.com> - 2011-04-26 16:03 +0200
Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 18:08 +0200
Re: Py_INCREF() incomprehension Hegedüs Ervin <airween@gmail.com> - 2011-04-26 19:28 +0200
Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-26 19:45 +0200
Re: Py_INCREF() incomprehension Hegedüs Ervin <airween@gmail.com> - 2011-04-26 20:44 +0200
Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-27 11:58 +0200
Re: Py_INCREF() incomprehension Hegedüs Ervin <airween@gmail.com> - 2011-05-01 22:00 +0200
Re: Py_INCREF() incomprehension Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-02 10:48 +1200
Re: Py_INCREF() incomprehension Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-05-02 02:59 +0200
Re: Py_INCREF() incomprehension Hegedüs, Ervin <airween@gmail.com> - 2011-05-02 08:41 +0200
Re: Py_INCREF() incomprehension Stefan Behnel <stefan_ml@behnel.de> - 2011-05-02 09:07 +0200
csiph-web