home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!elroy.jpl.nasa.gov!ames!kronos.arc.nasa.gov!joshr
- From: joshr@kronos.arc.nasa.gov (Joshua Rabinowitz-Summer-91)
- Subject: thinkc5 DIRECT classes
- Message-ID: <1992Jul28.215321.18801@kronos.arc.nasa.gov>
- Summary: making CObject DIRECT
- Keywords: thinkc CObject direct
- Sender: usenet@kronos.arc.nasa.gov (Will Edgington, wedgingt@ptolemy.arc.nasa.gov)
- Nntp-Posting-Host: kronos-arclan.arc.nasa.gov
- Organization: NASA/ARC Information Sciences Division
- Distribution: comp.sys.mac.programmer
- Date: Tue, 28 Jul 1992 21:53:21 GMT
- Lines: 34
-
- Hey fellow netters:
-
- this may be a FAQ, but I doubt it. Iv'e seen little reference to the subject
- anywhere.
-
- What I'm looking into is re-writing the CObject class as a direct, that
- is, not a handle but a reference. My original thinking is that
- if I rewrote new() and delete() to call NewPtr() and DisposPtr(), and
- recompiled, all the objects would then be direct.
-
- This should speed up some operations, because the constant double-
- dereferencing would be eliminated. Of course it presents
- mem. fragmentation problems, but this may not be a problem.
-
- When I tried it once, CopyObject was the problem:
- you cannot tkae sizeof(this), so one way to figure out the size of
- the object to be copied is GetPtr/HandleSize().
-
- When I implemented this, the starter project crashed, and hard. Complete
- lockup.
-
- Has anyone tried this? aAre there other reasons to avoid it?
-
- Your thoughts and comments are welcome.
-
- joshr@kronos.arc.nasa.gov
-
-
-
- --
- ----------------------------------
- #include <std/disclaimer.h> Josh Rabinowitz, Mac TCL programmer
- joshr@kronos.arc.nasa.gov
- "'I see', said the blind carpenter, as he picked up his hammer and saw".
-