[Python-Dev] #ifdef __cplusplus?

[M.-A. Lemburg]

On 2009-01-02 08:26, Adam Olsen wrote:
> On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen <rhamph at gmail.com> wrote:
>> ..
>>> As C++ has more specific ways of allocating memory, they impose this
>>> restriction to annoy you into using them.
>> And so does Python API: see PyMem_NEW and PyMem_RESIZE macros.
> 
> An optional second API provides convenience, not annoyance.  Besides,
> they're not used much anymore.  I am curious what their history is
> though.

See Include/pymem.h and objimpl.h for details.

PyMem_MALLOC() et al. provide an abstraction layer on top of the system's
malloc() implementation. PyObject_MALLOC() et al. use the Python
memory allocator instead.

>>>  We won't be using them, and the extra casts and nothing but noise.
>> A quick grep through the sources shows that these casts are not just nose:
>>
>> Objects/stringobject.c: op = (PyStringObject *)PyObject_MALLOC(..
>> Objects/typeobject.c:   remain = (int *)PyMem_MALLOC(..
>> Objects/unicodeobject.c:        unicode->str = (Py_UNICODE*) PyObject_MALLOC(..
>>
>> in many cases the type of object being allocated is not obvious from
>> the l.h.s. name.  Redundant cast improves readability in these cases.
> 
> 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.

> 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.

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.

>>>  Figure out a way to turn off the warnings instead.
>>>
>> These are not warnings: these are compile errors in C++.  A compiler
>> which allows to suppress them would not be a standard compliant C++
>> compiler.
> 
> So long as the major compilers allow it I don't particularly care.
> Compiling as C++ is too obscure of a feature to warrant uglifying the
> code.
> 
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 02 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/