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

M.-A. Lemburg mal at egenix.com
Fri Jan 2 17:05:19 CET 2009

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 PyMemNEW and PyMemRESIZE 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 *)PyObjectMALLOC(.. Objects/typeobject.c: remain = (int *)PyMemMALLOC(.. Objects/unicodeobject.c: unicode->str = (PyUNICODE*) PyObjectMALLOC(.. 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(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.

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

More information about the Python-Dev mailing list