On Fri, 15 Mar 2002, Tim Peters wrote:
> and _THIS_MALLOC is a macro exapnding to PyCore_OBJECT_MALLOC_FUNC, and
> PyCore_OBJECT_MALLOC_FUNC is a macro expanding to _PyCore_ObjectMalloc when
> pymalloc is enabled. _PyCore_ObjectMalloc is not a macro, it's the actual
> ultimate name of the malloc substitute (ignoring the possibilities for
> somone to break into the macro chain). All *these* macro names are supposed
> to be "invisible" (internal to the memory implementation).
>
> In the other direction, e.g.,
>
> PyObject_New ->
> _PyObject_New ->
> PyObject_MALLOC ->
> PyCore_OBJECT_MALLOC ->
> PyCore_OBJECT_MALLOC_FUNC,
> and we're back in the macro chain traced above
>
> There's just no sane way to say "give me obmalloc.c's malloc". I'd rather
> we named obmalloc.c's entry points, e.g., PyMalloc_Malloc directly ...
When I did some experiments with using pymalloc for all allocation in the
interpreter, the above was a pain in figuring out what to change.
I find the explicit naming approach you suggest attractive.
I plan to have another look at those old experiments (things pretty
much worked, but there was a savage performance hit...).
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370
andymac@pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4