Go to the first, previous, next, last section, table of contents.

# Library dynamic allocation primitives

Libg++ contains versions of `malloc, free, realloc` that were designed to be well-tuned to C++ applications. The source file ``malloc.c'` contains some design and implementation details. Here are the major user-visible differences from most system malloc routines:

1. These routines overwrite storage of freed space. This means that it is never permissible to use a `delete`'d object in any way. Doing so will either result in trapped fatal errors or random aborts within malloc, free, or realloc.
2. The routines tend to perform well when a large number of objects of the same size are allocated and freed. You may find that it is not worth it to create your own special allocation schemes in such cases.
3. The library sets top-level `operator new()` to call malloc and `operator delete()` to call free. Of course, you may override these definitions in C++ programs by creating your own operators that will take precedence over the library versions. However, if you do so, be sure to define both `operator new()` and `operator delete()`.
4. These routines do not support the odd convention, maintained by some versions of malloc, that you may call `realloc` with a pointer that has been `free`'d.
5. The routines automatically perform simple checks on `free`'d pointers that can often determine whether users have accidentally written beyond the boundaries of allocated space, resulting in a fatal error.
6. The function `malloc_usable_size(void* p)` returns the number of bytes actually allocated for `p`. For a valid pointer (i.e., one that has been `malloc`'d or `realloc`'d but not yet `free`'d) this will return a number greater than or equal to the requested size, else it will normally return 0. Unfortunately, a non-zero return can not be an absolutely perfect indication of lack of error. If a chunk has been `free`'d but then re-allocated for a different purpose somewhere elsewhere, then `malloc_usable_size` will return non-zero. Despite this, the function can be very valuable for performing run-time consistency checks.
7. `malloc` requires 8 bytes of overhead per allocated chunk, plus a mmaximum alignment adjustment of 8 bytes. The number of bytes of usable space is exactly as requested, rounded to the nearest 8 byte boundary.
8. The routines do not contain any synchronization support for multiprocessing. If you perform global allocation on a shared memory multiprocessor, you should disable compilation and use of libg++ malloc in the distribution ``Makefile'` and use your system version of malloc.

Go to the first, previous, next, last section, table of contents.