home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12490 < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.2 KB  |  83 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!mel.dit.csiro.au!mineng.dmpe.CSIRO.AU!dmssyd.syd.dms.CSIRO.AU!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Tagged Pointers
  5. Message-ID: <1992Aug18.013357.19262@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <1992Aug14.234242.8418@ucc.su.OZ.AU> <1992Aug17.174931.1376@fcom.cc.utah.edu>
  10. Date: Tue, 18 Aug 1992 01:33:57 GMT
  11. Lines: 70
  12.  
  13. In article <1992Aug17.174931.1376@fcom.cc.utah.edu> swillden@news.ccutah.edu (Shawn Willden) writes:
  14. >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  15. >
  16. >:     It all depends on whether tagged pointers are a genuine
  17. >: type or not. If it is, all the above things must be distinct.
  18. >: If not (I suggested not in my post) then maybe we can make
  19. >: a pointer to a tagged union work as if it were a tagged
  20. >: pointer. This would homogenise the interface. More work
  21. >: for the compiler, less for the programmmer. Less control
  22. >: for the programmer too.
  23. >
  24. >Hmmm.  It appears I didn't explain myself very well because that is
  25. >precisely what *I* was suggesting.  I suppose the difference lies in
  26. >my consideration of TP's and TU's as different types but (as I said)
  27. >
  28. >    1)    *TP yields a TU
  29. >    2)    &TU yields a TP
  30. >
  31. >whereas you suggested that they not be actual *types* but that we 
  32. >make them work like the above anyway.  Same effect, different words.
  33. >Have I got this right?
  34.  
  35.     I'll have to think on this carefully, everytime I try
  36. to reply I get confused :-)
  37.  
  38. >
  39. >:     So the issue is whether a tagged pointer is a proper type
  40. >: or just a sort of syntactic sugaring that supports a new 
  41. >: mechanism for genericity. My thinking was the latter.
  42. >
  43. >I think your thinking is better :-)  TP couldn't be a proper type
  44. >anyway.  If anything, TP would be a *family* of types.
  45. > 
  46. >:     Any comments?
  47. >
  48. >Getting back to the question that started this exchange (should we have
  49. >tagged references?), I think that they're probably unnecessary for the
  50. >case I was presenting (by which I mean that they don't greatly simplify 
  51. >anything).  If I have a TP and wish to pass a reference to what it points 
  52. >to to a function I can just say:
  53. >
  54. >void foo([T1,T2,T3]& fred)    // fred is a ref to a TU, not a tagged ref.
  55. >    {...}
  56. >
  57. >void bar();
  58. >    {
  59. >    [T1,T2,T3]* barney;
  60. >    ...
  61. >    foo(*barney);        // *barney is a TU, foo gets a ref to it.
  62. >    }
  63. >
  64. >at least that is what the programmer may think.  In fact TU and TP are not
  65. >types but the syntax of the sugar looks right.  Actually, does it really 
  66. >matter whether we call [T1,T2,T3]& a ref to a tagged union or a tagged 
  67. >ref?
  68. >
  69.  
  70.     Yes. The compiler has to know where to find the tag,
  71. next to the pointer, or where the pointer is pointing.
  72. The rule has to be next to the pointer. So taking the address
  73. or making a reference to a tagged union has to copy the tag.
  74.  
  75.     To work out the exact rules I think in terms of the implementation.
  76. I'll have a go soon, perhaps while on holidays. 
  77.  
  78. -- 
  79. ;----------------------------------------------------------------------
  80.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  81.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  82. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  83.