Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!swrinde!ucsd!dog.ee.lbl.gov!ux5.lbl.gov!beard
From: beard@ux5.lbl.gov (Patrick C Beard)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think C Objects in motion???
Keywords: Think C Objects are handles.
Message-ID: <6988@dog.ee.lbl.gov>
Date: 16 Sep 90 00:01:23 GMT
References: <1990Sep14.105646.23614@cunixf.cc.columbia.edu>
Sender: usenet@dog.ee.lbl.gov
Reply-To: beard@ux5.lbl.gov (Patrick C Beard)
Organization: Berkeley Systems, Inc.
Lines: 59
X-Local-Date: Sat, 15 Sep 90 17:01:23 PDT

In article <1990Sep14.105646.23614@cunixf.cc.columbia.edu> wlj1@cunixb.cc.columbia.edu (Wayne L Jebian) writes:
#
#I've noticed some strange behavior from the TCL.
#
#Sometimes when I execute a toolbox call from within a method, I get the 
#ubiquitous odd address error. This had me _REALLY CONFUSED_ until I
#tried putting the offending calls in other places: that is,
#in glue that put the trap calls outside the object's struct.

This last sentence doesn't make any sense, really, I assume you meant that
you can fix it if you call the toolbox outside of an object's method.

#Well, now my code doesn't break but I'm still confused. Is code (the methods)
#being moved around without updating the PC? I thought that the objects could
#be treated transparently as pointers - i.e. no locking required.

1.  The code/method of an object is just regular C code, and therefore it
won't move unless you specifically mark the segment purgeable.

2.  Objects are handles, not pointers, and therefore have to be treated with
kindness.  The rule is, don't assign into an object's fields if the rhs of
the assignment can move memory.  For example:

struct MyObject {
/* methods. */
	void IMyObject();

/* data. */
	Handle itsData;
};

void MyObject::IMyObject()
{
	itsData = NewHandle(1024);	/* dangerous, NewHandle moves memory */
	{
		Handle temp = NewHandle(1024);
		itsData = temp;
	}
}

The first assignment is dangerous, the second is safe.  I'm guessing that
this is the problem you were experiencing.  Alternatively, you can lock your
object:

void MyObject::Lock()
{
	HLock((Handle)this);
}

Use this method when you are about to do something dangerous like the
above assignment.  However, using temporary variables is actually faster,
because you can avoid all those implicit double dereferences.


--
-------------------------------------------------------------------------------
-  Patrick Beard, Macintosh Programmer                        (beard@lbl.gov) -
-  Berkeley Systems, Inc.  ".......<dead air>.......Good day!" - Paul Harvey  -
-------------------------------------------------------------------------------