[Python-Dev] #ifdef __cplusplus?

[M.-A. Lemburg]

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(Py_UNICODE).
>>>
>>> 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,GC_New,GC_NewVar} 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 PyMem_New() 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 PyMem_NEW() (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 PyMem_Malloc (or even providing a
> different PyMem_Malloc).

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/