home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / mac / programm / 15448 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  2.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!data.nas.nasa.gov!taligent!apple!mumbo.apple.com!gallant.apple.com!NewsWatcher!user
  2. From: nerm@apple.com (Dean Yu)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: handles and MoveHHi
  5. Message-ID: <nerm-140992103237@90.10.20.86>
  6. Date: 14 Sep 92 17:36:44 GMT
  7. References: <1992Sep13.161238.28426@welchgate.welch.jhu.edu> <D88-JWA.92Sep13193711@cyklop.nada.kth.se>
  8. Sender: news@gallant.apple.com
  9. Followup-To: comp.sys.mac.programmer
  10. Organization: Apple Computer, Inc.
  11. Lines: 43
  12.  
  13. In article <D88-JWA.92Sep13193711@cyklop.nada.kth.se>,
  14. d88-jwa@cyklop.nada.kth.se (Jon W{tte) wrote:
  15. > 
  16. > > francois@welchgate.welch.jhu.edu (Francois Schiettecatte) writes:
  17. > 
  18. >    - is there a real advantage to using MoveHHi before locking your
  19. >    handles, I have not really seen much on that except that Think Reference
  20. >    suggests that is *may* help in reducing heap fragmentation. Are there
  21. >    any definite rules for using MoveHHi and caveat.
  22. > 
  23. > MoveHHi is, uh, somewhat expensive since the toolbox
  24. > goes to a fair amount of trouble to move stuff out of
  25. > the way and move the handle HIGH up in the heap.
  26. > 
  27. > If you're going to keep the handle locked for a long
  28. > time (i.e. a minute or more...) it's a very good idea,
  29. > but if you only lock the handle to pass it to a toolbox
  30. > routine, it's no idea. (Or rather, a bad idea)
  31. > 
  32. >    - Also when passing parameters in C is it better to use pointers or
  33. >    handles. I guess the answer is really along the lines of it depends
  34. >    on what you do with them afterwards, ie do you lock them, do you need to 
  35. >    allocate new memory, etc. Does anyone have any guidelines for this.
  36. > 
  37. > Well, if it's a handle from the start, pass it as a handle
  38. > as far as possible, because you get more constrained when
  39. > you can't "do" anything with a handle. Also, if your function
  40. > takes a pointer, never assume that's a dereferenced handle.
  41. > RecoverHandle is EXPENSIVE! The reverse is also true; don't
  42. > pass the address of a pointer to something that wants a handle.
  43. > 
  44.  
  45.   In addition to what Jon said, if you're using a handle for the sake of
  46. using a handle, and you keep it locked for the duration of your program's
  47. life, you might as well use a pointer and save yourself a dererference.
  48. This won't cost you much in terms of fragmentation, since pointers are
  49. created as low in the heap as possible.  If you create all the pointers you
  50. need early in your program, your non-relocatable blocks should be neatly
  51. organized at the bottom of your heap.
  52.  
  53. -- Dean Yu
  54.    Blue Meanie, Negative Ethnic Role Model, etc.
  55.    Apple Computer, Inc.
  56.