home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11847 < prev    next >
Encoding:
Internet Message Format  |  1992-07-31  |  4.6 KB
  1. Xref: sparky comp.lang.c++:11847 comp.std.c++:1005
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!netmbx!jrobie
  4. From: jrobie@netmbx.netmbx.de (Jonathan Robie)
  5. Subject: Re: run-time type checking, freezing, and thawing
  6. Organization: netmbx, Berlin, Germany
  7. Date: Fri, 31 Jul 1992 12:49:56 GMT
  8. Message-ID: <FAM5HFE@netmbx.netmbx.de>
  9. References: <BryL9q.K5I@watcgl.waterloo.edu> <2A75837D.8B10@tct.com> <2TJ53BQ@netmbx.netmbx.de> <2A78457A.561C@tct.com>
  10. Lines: 104
  11.  
  12. chip@tct.com (Chip Salzenberg) writes:
  13.  
  14. >According to jrobie@netmbx.netmbx.de (Jonathan Robie):
  15. >>
  16. >>RTTI is needed to properly freeze a C++ object into a "dead array of
  17. >>bytes" ...
  18.  
  19. >Virtual functions are sufficient for freezing.
  20.  
  21. Somebody out there is not listening.  When I say "necessary" I do not
  22. mean that it is impossible for an application programmer to write lots
  23. of code that I could use to do a task.  I simply mean that this info is
  24. not out there unless the compiler or the application programmer supplies it.
  25. Since the compiler has the info and then throws it away I would rather get
  26. it from the compiler, and information gotten from the compiler is also more
  27. likely to be correct...
  28.  
  29. >>... and to turn a "dead array of bytes" into a C++ object.
  30.  
  31. >RTTI is of zero relevance to thawing.  It doesn't make this code work:
  32.  
  33. >    int i;
  34. >    char *buf;
  35. >    read(fd, &i, sizeof(int));
  36. >    buf = new char[i];
  37. >    read(fd, buf, i);
  38. >    XXX *foo = thaw_arbitrary_object(buf, i);
  39.  
  40. Good thing, too!  Would you *want* it to make that code work? :->
  41. It *does*, however, make this code work:
  42.  
  43.     PersonAllSet.Get(pPerson);
  44.  
  45. That is the code to read the next person out of the Person AllSet in
  46. a database.  It works properly regardless of the derived type of the
  47. person (plumber, presidential candidate, gigolo, software developer...)
  48. and restores the object which was originally stored.  Note that the
  49. actual offsets of an object in memory may vary from one executable to
  50. another, so you have to find the location and type of the data members
  51. at run time.
  52.  
  53. This *can* be done using virtual functions, two for every single data
  54. member in the class (one to get the member, one to set it), plus an
  55. additional member function to identify the parent of the class.  But
  56. these virtual functions make all the data members of the object accessible
  57. in the whole program, and therefore break encapsulation!  You *do* want
  58. private and protected members to be stored in the database without making
  59. them publically accessible, don't you??
  60.  
  61. If these members are accessed only through run time type identification
  62. then encapsulation and data hiding are preserved *except* for those
  63. functions which use run time type identification.
  64.  
  65. If virtual functions are written then you have opened your objects
  66. up to everybody.  This is true whether the programmer must write all
  67. these functions (ugh!) or a precompiler does the work (ugh! -- how many
  68. precompilers do we want to replace the information thrown away by the
  69. compiler!).  Of course, you could make all these functions private and
  70. make yourself a friend of each class.  Maybe two or three other libraries
  71. will want to do the same, and maybe their naming conventions will clash,
  72. the signatures of the member functions will be incompatible, the precompilers
  73. will be incompaible with each other...
  74.  
  75. >>It is also needed to follow references among objects in RAM.
  76.  
  77. >I can do that without RTTI right now.
  78.  
  79. An object oriented database or other general purpose tool which does not
  80. know your data types can not.  This was the context of my previous message.
  81. If you want the database to store, retrieve, or query a network of objects
  82. then it needs access to run time type identification.
  83.  
  84. >>RTTI and persistence are related enough that all of the major C++
  85. >>database systems use precompilers to get at it.
  86.  
  87. >The mere fact that RTTI can be used for freezing proves neither (1)
  88. >that it is necessary for freezing, nor (2) that it is useful -- much
  89. >less necessary -- for thawing.
  90.  
  91. No, but the fact that nobody seems to have done it successfully without it
  92. might mean something, given that nobody writes a precompiler if they have
  93. a choice.
  94.  
  95.  
  96. Jonathan
  97.  
  98. ======================================================================
  99.  
  100. Jonathan Robie        jrobie@netmbx.UUCP
  101. Arnold-Zweig-Str. 44    jrobie@netmbx.in-berlin.de
  102. O-1100 Berlin        
  103. Deutschland        Phone:  +37 (2) 472 04 19  (Home, East Berlin)
  104.                 +49 (30) 342 30 66 (Work, West Berlin)
  105.  
  106. The opinions expressed in this message are not necessarily those
  107. of my employer, but they should be yours.
  108.  
  109.  
  110.  
  111. -- 
  112. Jonathan
  113.  
  114. ===========================================================================
  115.  
  116.