home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3513 < prev    next >
Encoding:
Text File  |  1992-11-07  |  2.3 KB  |  45 lines
  1. Newsgroups: comp.lang.misc
  2. Path: sparky!uunet!pmafire!mica.inel.gov!ux1!fcom.cc.utah.edu!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
  3. From: jlg@cochiti.lanl.gov (J. Giles)
  4. Subject: Re: Pointers
  5. Message-ID: <1992Nov5.213541.11684@newshost.lanl.gov>
  6. Sender: news@newshost.lanl.gov
  7. Organization: Los Alamos National Laboratory
  8. References: <1992Nov4.093545.15950@rdg.dec.com> <Bx7oAz.7Lp@mentor.cc.purdue.edu> <1992Nov5.014143.15635@newshost.lanl.gov> <1dbqs8INN7qo@early-bird.think.com>
  9. Date: Thu, 5 Nov 1992 21:35:41 GMT
  10. Lines: 33
  11.  
  12. In article <1dbqs8INN7qo@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
  13. |> [...]
  14. |> That's a silly guideline.  The most common reason to use pointers is
  15. |> precisely *because* you need multiple references to the same data.  In
  16. |> object-based programming, an object may be in different relationships with
  17. |> other objects, and relationships are usually implemented as pointers
  18. |> between objects.  For instance, in a family tree model, a person might have
  19. |> pointers to its parents, children, and siblings; any particular person is
  20. |> likely to be referenced by the children array of two parents and a parent
  21. |> pointer of some children.
  22.  
  23. I seldom use explicit pointers for this kind of structure.  It 
  24. consists of a *set* of individuals and *sets* of directed arcs 
  25. between these individuals.  The directed arcs are not semantically 
  26. just pointers, they are ordered pairs whose elements are drawn from 
  27. the set of individuals.  Each such set of arcs defines one of
  28. the relations you mentioned above: parenthood, siblinghood, etc..
  29. While these may be *implemented* internally using pointers, the 
  30. finite, non-looping, non-aliased nature of these sets allows more 
  31. efficient code development which is easier to prove correct, optimize, 
  32. maintain, etc..  For example, suppose I wish to perform some operation 
  33. on all individuals - I needn't even *look* at the sets of arcs if the 
  34. order of processing the individuals is not relevant (or, if the order 
  35. is intended to be, say, alphabetical so the sets of arcs you mention 
  36. are all irrelevant). 
  37.  
  38. In fact, I never think in terms of multiple *pointers* to a single 
  39. object - though I might think in terms of multiple references of 
  40. more restricted, more easily handled, optimizable, and debuggable
  41. kinds.
  42.  
  43. -- 
  44. J. Giles
  45.