Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #4043

Re: Py_INCREF() incomprehension

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)

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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