C++ use of Malloc/Realloc and Free

[gaf at blu.org (Jerry Feldman)]

On Tue, 24 Jun 2003 13:00:24 -0400 (EDT)
markw at mohawksoft.com wrote:

> I have been lurking on this set of threads and I have a few notes.
> malloc et. al. are also very poor for performance. The memory heap is
> often times a point of contention for multi-threaded programs.
While this may be true. Most compilers use malloc as the underlying
allocation for the C++ new operator. But there are some caveats here
beyond what has been discussed. Because new is an operator, it also may
be overridden. And, some classes that override this may themselves use
malloc. (Again, just to reiterate, you need to know what you are doing
when you use malloc(and calloc and realloc) in C++).  So, the
performance issue also affects the new operator. 

Threads are an interesting issue because each thread has its own stack,
and the thread's stack may be more limited than the process' stack
causing serious problems if you use alloca. And, the proper underlying
implementation of malloc for threads should have the freelist properly
protercted by a mutex. 

Some newer malloc implementations now use mmap(2) rather than brk(2) and
sbrk(2). 

Again, the bottom line is "use malloc(3), realloc(3), calloc(3),
alloca(3) and free(3) in C++ at your own risk". If you know what the
underlying implementation does, then you should have no problem. But
also remember that on Linux, the underlying libraries can change without
 notice so that your application may not be portable accross platforms. 

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20030624/b2e856b3/attachment.sig>