home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11470 < prev    next >
Encoding:
Text File  |  1992-07-24  |  4.4 KB  |  115 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!math.fu-berlin.de!zrz.tu-berlin.de!news.netmbx.de!netmbx!jrobie
  3. From: jrobie@netmbx.netmbx.de (Jonathan Robie)
  4. Subject: Re: Covariant Types in Derived Classes
  5. Organization: netmbx, Berlin, Germany
  6. Date: Fri, 24 Jul 1992 14:17:57 GMT
  7. Message-ID: <VKE52M@netmbx.netmbx.de>
  8. References: <92A5AID@netmbx.netmbx.de> <1992Jul21.183932.1541@ucc.su.OZ.AU> <P6C5COF@netmbx.netmbx.de> <1992Jul23.205820.24559@ucc.su.OZ.AU>
  9. Lines: 104
  10.  
  11. maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  12.  
  13. >>If I want a generic print function that can handle all types as though they
  14. >>were basic types, then this print function must know the location and type
  15. >>of each member, and also the name if the function is to be particularly
  16. >>useful.
  17.  
  18. >    Such a utility function would be useful for debugging only.
  19. >Yes, to do it you would need RTTI.
  20.  
  21. Not so.  A report generator might start by showing me the default
  22. printout for an object.  I can grab fields with my mouse and move
  23. them around or delete them.
  24.  
  25. A user interface tool might allow me to do something similar by providing
  26. me with a default, editable window.
  27.  
  28. Debugging is another obvious application, as you mention.
  29.  
  30. So far we have seen that RTTI is very useful for debuggers, class browsers,
  31. report generators, user interface tools, databases, communications...
  32. in other words, for a great deal of the programming tools a C++ programmer
  33. would like to have.
  34.  
  35. >    To make proper output *requires* programmer definition,
  36. >when I need this I just have a virtual print in all relevant classes.
  37. >Of course, then I have to *write* the definitions, which is a pain.
  38.  
  39. But providing a default which may be used directly or edited with
  40. a mouse is not a pain, and is easily provided as a general tool.
  41.  
  42. >    Oh, you mean that the database does NOT actually define new 
  43. >objects, the user has to write a program to create them?
  44. >(To supply the constructor, which must be compiled C++ code)
  45. >Then the OODB just stores the stuff, and has to retrieve
  46. >it and convert it back to an object, which is a bit
  47. >of a problem even WITH RTTI (because the object doesn't yet
  48. >exist, so the RTTI is useless).
  49.  
  50. Let me give you an example from POET, the OODB that I know
  51. best (because I am one of the developers).  Let's say you have
  52. an arbitrary class declaration:
  53.  
  54.     class ArbitraryClass {
  55.         int foo;
  56.     public:
  57.         float goo;
  58.     };
  59.  
  60. If you just write the little word "persistent" in front of this then
  61. our precompiler will know that it should generate run time type info:
  62.  
  63.  
  64.     persistent class ArbitraryClass {
  65.         int foo;
  66.     public:
  67.         float goo;
  68.     };
  69.  
  70. If an object is assigned to a database then you can store it using
  71. the Store() method, which is provided for all persistent objects:
  72.  
  73.     ArbitraryClass ArbitraryObject;
  74.  
  75.     ArbitraryObject->Assign(ADatabase);
  76.     ArbitraryObject->Store();
  77.  
  78. I'll avoid going into more detail right now, but you see that this
  79. is very convenient.  Without RTTI it is not possible.  We do not need
  80. a reflective system, but we do need an introspective system.  Since
  81. C++ is not introspective, we have built our own compiler to give us the
  82. information which all C++ compilers generate and then throw away.
  83.  
  84. >    Yes. 'tis why I am concerned that RTTI will be used
  85. >to do downcasting, which, although not invalidating type safety,
  86. >invalidates the open/closed principle.
  87.  
  88. I am concerned that many C++ programs downcast without any guarantee
  89. of type safety.  Start reading large C++ programs and you will see that
  90. downcasts are quite common.  Is the C++ community worse off if we provide
  91. a safer way to do this?
  92.  
  93. >    The problems you want to solve (me too, and many others :-)
  94. >are way out of te scope of a traditional language which
  95. >works only with memory resources. THAT is the problem, really.
  96.  
  97. Naw.  The problems *I* am discussing have  already been solved
  98. using C++, but we are finding sneaky ways to get at run time type
  99. information.
  100.  
  101. >    Wouldn't you rather just say 'persistent' and have the object
  102. >just exist in the 'persistent'  database totally automatically :-)
  103.  
  104.     Because the user shyould have some control over which objects
  105.     get stored, and should be able to test the store operation for
  106.     error returns.  But you have the right idea!  And if you look
  107.     at my sample code given above--from a commercial system that
  108.     is now available--you see that this kind of high level access
  109.     is possible in C++ today, given RTTI.
  110. -- 
  111. Jonathan
  112.  
  113. ===========================================================================
  114.  
  115.