[ Fabrizio Oddone | Italian Recipes | Ricette Italiane | Y2K | Site Map | What's New ]


Last updated: March 3, 2001

Latest version: 1.0.1


email me and I will send you a copy
mallocfree is meant to be used by programmers instead of the ANSI C library memory manager. It includes malloc, free, realloc, calloc, and as additional goodies getallocsize (works like _GetPtrSize/_GetHandleSize on a mallocated block; the ANSI libraries lack this routine) and ffcalloc (you pass a single parameter instead of the two parameters you are forced to give to the standard calloc; this lets you avoid a multiplication at runtime).

Q.: Why should I use mallocfree? _NewPtr and _NewHandle work just fine!
A.: If you are allocating/disposing memory in a time-sensitive section of code, you will discover that the Mac Memory Manager is slow, and might become a bottleneck. These routines are fast enough for most uses.

Q.: Why should I use mallocfree? The ANSI libraries supplied with my compiler work just fine.
A.: When I was optimizing the GW-Ada/Ed-Mac compiler, it turned out that something was hysterically filling its own application heap with blocks; the bigger its memory partition, the more infuriatingly you jumped into MacsBug with error #25. The culprit was the ANSI memory manager, whose realloc routine was buggy in both Symantec and CodeWarrior 4.5 (never tried with CW 5.x or later). My realloc works fine.

If you use:


the blocks will be allocated in temporary memory or in your own heap, whichever has more memory free. Otherwise, your own heap only will be used.

If you use:

#define USE64BITUNITS 1

the blocks will have a physical size (in bytes) which is a multiple of 8 (as in the original K&R version). Otherwise, a multiple of 4 will be used; it saves memory.

This page was last built with Frontier on a Macintosh on Mon, Apr 22, 2002 at 9:43:36 PM by
Fabrizio Oddone, fab@kagi.com