[Python-Dev] #ifdef __cplusplus?
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 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
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++
> 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
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
More information about the Python-Dev