home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12390 < prev    next >
Encoding:
Text File  |  1992-08-15  |  2.9 KB  |  79 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Downcasting (was: Re: run-time type checking)
  5. Message-ID: <1992Aug16.061849.28208@ucc.su.OZ.AU>
  6. Keywords: polymorphism, RTTI, downcasts.
  7. Sender: news@ucc.su.OZ.AU
  8. Nntp-Posting-Host: extro.ucc.su.oz.au
  9. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  10. References: <1992Aug5.110132.8756@ucc.su.OZ.AU> <9222518.29381@mulga.cs.mu.OZ.AU> <1992Aug14.165432.14403@mole-end.matawan.nj.us>
  11. Date: Sun, 16 Aug 1992 06:18:49 GMT
  12. Lines: 65
  13.  
  14. In article <1992Aug14.165432.14403@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
  15. >>         operator Derived1*() { return this; }
  16. >>     };
  17.  
  18.     Aslo,
  19.  
  20.     class Base {
  21.         downcastable D1, D2;
  22.     ...
  23.     
  24. >
  25. >The problem with this is that it requires explicit functions all over
  26. >the place.  
  27.  
  28.     The second form requires it only in the base class.
  29. (Downcastability is obviously inherited)
  30.  
  31. >It swells the interfaces (trust me, I've seen it used, even
  32. >suggested it as the best possible in C++ today), swells the vtables, 
  33.  
  34.     If we use RTTI it doesnt impact the system beyond
  35. what RTTI would anyway. 
  36.  
  37. >may
  38. >thereby interefere with some language implementations, and makes the
  39. >code brittle.
  40. >
  41. >But I like the idea of declarations in the derived type permitting or
  42. >blocking an RTTI-based conversion.
  43.  
  44.     The problem with putting the permission in the derived class
  45. is that it doesn't solve the original problem (if there was one)
  46. that being able to downcast from a base violates the BASE classes
  47. integrity.
  48.  
  49.     My premise is that the MOTHER of an object (the code
  50. doing the 'new') knows the objects exact type (secret name),
  51. and has control over who gets hold of it (when you 
  52. know an objects secret name you have total power over it,
  53. elementary principle of magic, and isn't programming just a 
  54. form of magic :-)
  55.  
  56.     At this level, downcastability is easily controlled on
  57. an object by object basis, the MOTHER making a list of
  58.     {Base*, Derived*}
  59. and passing the list to trusted confidants dynamically.
  60. The declaration 'downcastable D' in the base class B is 
  61. equivalent to puting the list in a static variable in the
  62. base class--everone with access to the base is granted
  63. permission to downcast to the nominated derived class,
  64. which is now an integral part of the base classes interface.
  65.  
  66.     Other methods of passing around secret names include
  67. tagged pointers, which have the advantage of static type
  68. correctness that no other method has. Because of this
  69. IMHO tagged pointers should be implemented anyhow, since they
  70. are the best mechanism available when they actually do
  71. the job (which is not always).
  72.  
  73.  
  74. -- 
  75. ;----------------------------------------------------------------------
  76.         TIM (TAL) LISTER,         maxtal@extro.ucc.su.oz.au
  77.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  78. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  79.