Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!brahms.berkeley.edu!lippin
From: lippin@brahms.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HandleObject vs. 5+ meg of RAM and Virtual Memory
Message-ID: <1990Jul6.190245.5781@agate.berkeley.edu>
Date: 6 Jul 90 19:02:45 GMT
References: <279@unf7.UUCP>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: lippin@math.berkeley.edu
Organization: University of California, Berkeley
Lines: 42

Recently shite@unf7.UUCP (Stephen Hite) wrote:
>   If I have 5 or 8 meg of RAM and virtual memory (a.k.a System 7.0.2 :-))
> is it really *worth* the limitations of using HandleObject?

In a word, no.  In four words, both yes and no.  And neither answer
depends on how much memory you have, virtual or not.

A popular misconception about C++ is that since its native objects are
"Pointer based" a call to NewPtr (or worse, malloc) is made for each
object.  The truth is that a native class works just like a struct --
if it's local, it goes on the stack; if global, it goes in global
space; if allocated with new, then it goes into the heap.

Most of my classes are C++ native ones.  They don't fragment the heap
at all -- mostly they're on the stack or in global space.  When they
are on the heap, I can put them in a handle, or even in part of a
larger structure that I put into the handle.  (As usual, I have to
keep an eye out for relocation -- it would be bad to have "this" slide
out from under a method.  But that's no worse than with any other
parameter.  Lock the handle, make a copy on the stack, or just don't
move memory, as appropriate.)

Of course, you do need HandleObjects and PascalObjects for dealing
with MacApp, and they're handy for classes you really want to store
that way.  Just don't think every object has to be one.

My recommendation is to ignore the different kinds of objects until
you've figured out how you want to store a thing.  Then choose the
kind of object that stores it where you want it.

A final note on virtual memory: handles are still important.  A
fragmented virtual memory leads to thrashing, while an unfragmented
one will map better into physical memory.  The combination of handles
and virtual memory will be a great strength of system 7.  On the other
hand, a weakness of the system 7 memory manager is fixed heap sizes.
This weakness is also less important if you keep a clean heap.

						--Tom Lippincott
						  lippin@math.berkeley.edu

	"It's a poor sort of memory that only works backwards."
						--Lewis Caroll