[Python-Dev] #ifdef __cplusplus? (original) (raw)

M.-A. Lemburg mal at egenix.com
Mon Jan 5 13:13:56 CET 2009


On 2009-01-03 04:15, Adam Olsen wrote:

On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg <mal at egenix.com> wrote:

On 2009-01-02 08:26, Adam Olsen wrote:

Python's malloc wrappers are pretty messy. Of your examples, only unicode->str isn't obvious what the result is, as the rest are local to that function. Even that is obvious when you glance at the line above, where the size is calculated using sizeof(PyUNICODE).

If you're concerned about correctness then you'd do better eliminating the redundant malloc wrappers and giving them names that directly match what they can be used for. ??? Please read the comments in pymem.h and objimpl.h. I count 7 versions of malloc. Despite the names, none of them are specific to PyObjects. It's pretty much impossible to know what different ones do without a great deal of experience.

Is it ? I suggest you read up on the Python memory management and the comments in the header files. The APIs are pretty straight forward...

http://docs.python.org/c-api/allocation.html http://docs.python.org/c-api/memory.html

Only very specialized uses need to allocate PyObjects directly anyway. Normally PyObject{New,NewVar,GCNew,GCNewVar} are better.

Better for what ? The APIs you referenced are only used to allocate Python objects.

The malloc() wrappers provide a sane interface not only for allocating Python objects, but also for arbitrary memory chunks, e.g. ones referenced by Python objects.

If the size calculation bothers you you could include the semantics of the PyMemNew() API, which includes the cast you want. I've no opposition to including casts in a single place like that (and it would catch errors even with C compilation). You should always use PyMemNEW() (capital letters), if you ever intend to benefit from the memory allocation debug facilities in the Python memory allocation interfaces. I don't see why such debugging should require a full recompile, rather than having a hook inside the PyMemMalloc (or even providing a different PyMemMalloc).

Of course it does: you don't want the debug overhead in a production build.

The difference between using the NEW() macros and the MALLOC() macros is that the first apply overflow checking for you. However, the added overhead only makes sense if these overflow haven't already been applied elsewhere. They provide assertions. There's no overflow checking in release builds.

See above. Assertions are not meant to be checked in a production build. You use debug builds for debugging such low-level things.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Jan 05 2009)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/



More information about the Python-Dev mailing list