Message-ID: <35214AE5.E9225C28@johnbryce.co.il>
Date: Tue, 31 Mar 1998 22:58:29 +0300
From: Noam Rotem <nrotem AT johnbryce DOT co DOT il>
Organization: John Bryce Training Centre L.T.D
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Dynamic allocated memory. WAS: Linked lists
References: <3 DOT 0 DOT 5 DOT 32 DOT 19980329185251 DOT 007a4430 AT vip DOT cybercity DOT dk> <1998033023390501 DOT SAA29429 AT ladder01 DOT news DOT aol DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Myknees wrote:

> Since the way you access the data is by going down the chain of elements
> (nodes) in order, it is very slow if you have a long list where you won't be
> using the elements in order.  An alternative is to have a dynamically-allocated
> array of pointers to the structs.  That's much faster for random access and
> doesn't cost more in memory, since the structs don't need to contain a pointer
> to the next struct.  Of course, when you use an array you lose the ability to
> insert and delete elements easily and efficiently.

I know that dynamic allocations by malloc are kept in  a linked list of memory
blocks + overhead of data.  Is there any operation involving this list, which is
not of o(1)? (Well, except for freeing it all?) If so, why linked lists?

BTW,

This pool (heap?) of dynamic allocated memory is shared with other programs or
tasks? If so, how come I get dynamic and non dynamic allocations in the same
segment of memory?
If not, why should I free everything (or let it be done for me)? Could this memory
be still marked as taken even after my program has terminated?

---------------------------------------------
Noam Rotem
John Bryce Training Centre
Tel Aviv, Israel.
03-7535803
=============================================