Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!iconsys!ohs!stay
From: stay@ohs.uucp (Steve Taylor)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Linked Lists: Handles or Pointers?
Summary: and what about this?
Message-ID: <1991Jan26.191739.26088@ohs.uucp>
Date: 26 Jan 91 19:17:39 GMT
References: <1991Jan23.002212.7648@umiami.ir.miami.edu> <Mbbb8a_00Uh_I4wpkg@andrew.cmu.edu>
Organization: Alpine School District, Orem, Utah
Lines: 55

In article <Mbbb8a_00Uh_I4wpkg@andrew.cmu.edu>, rg2c+@andrew.cmu.edu (Robert Nelson Gasch) writes:
> I'm no expert on the subject, but here's my response:
> I'm not sure what the problem is. I Started programming in C a year ago
> and translated my linked list routines from Pascal without any problems.
> They use pointers only, no handles. If there's an issue of Mac programming
> I'm missing, please alert me, but I don't see any reason why a linked list
> should have to use handles. Even the head you can just malloc() and free(),
> so I see nothing that would require the use of handles.
> 
> --Rob

The quick answer (and I'm sure you'll have many) is that handles *aren't*
required.  However, pointers compact and fragment the heap.  See
Scott Knaster's book "How To Write Macintosh Software" and IM II p36.

While we're on the subject, how does the world look on this idea:

typedef struct {
	int		id;
	int		score;
	...
} OneUnit;

typedef OneUnit      UnitList[1];
typedef UnitList     **UnitLHandle;
...
	UnitLHandle aHandle;

	aHandle = NewHandle(initialSize);

Using the amazing flexibility of C, we can access the array (**aHandle)[]
at any point we want, [e.g. (**aHandle)[8].id = 1234] and it's completely
dynamic, because we can always SetHandleSize(aHandle, newsize);

From my experience, these are the advantages:
   All the advantages of arrays (greatly improved access speed, (which is
     no small advantage when you're going through an entire list for one
     element) access to qsort(), fewer stray pointers, no "following"
     pointers for finding and deleting elements, etc.)
   Saved space (4 bytes for every "next" field in a linked list, 8 bytes for
     every "next" and "prev" in a doubly-linked list)
   Dynamic to whatever extent we want.

Disadvantages:
   It can be a very large block to have lying around in memory, relocateable
     or not.
   moves and deletes are (naturally) relatively slow, but BlockMove works
     nicely and (in my case) most of the time the user is looking, not
     changing or deleting.  (Yes, this WAS supposed to be the disadvantage
     section.)

So, what do you all think?  Should I be cowering in a corner?
-------------------------------------------------------------------------------
Life is the dress-rehearsal for Hell.
Steven H. Taylor        ohs!stay@iconsys.icon.com         trACE(tm) Development