home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12929 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  2.9 KB
  1. Path: sparky!uunet!cimshop!davidm
  2. From: davidm@consilium.com (David S. Masterson)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: File I/O using C++ (write/read objects...)
  5. Message-ID: <DAVIDM.92Aug26132938@consilium.com>
  6. Date: 26 Aug 92 20:29:38 GMT
  7. References: <1992Aug26.023255.10785@gucis.cit.gu.edu.au>
  8. Sender: root@cimshop.UUCP
  9. Organization: Consilium Inc., Mountain View, California
  10. Lines: 49
  11. In-reply-to: jetherid@gucis.cit.gu.edu.au's message of 26 Aug 92 02:32:55 GMT
  12. X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]
  13.  
  14. >>>>> On 26 Aug 92 02:32:55 GMT, jetherid@gucis.cit.gu.edu.au (Jason
  15. >>>>> Etheridge) said:
  16.  
  17. > I am having real problems reading and writing objects to a file.  A text
  18. > I have uses
  19.  
  20. >     out.write((unsigned char*) &object, sizeof(OBJECT))
  21.  
  22. > where out is an fstream that allows writing to the file it is open for,
  23. > and object is an object of class OBJECT.
  24.  
  25. > It writes the object, seemingly with no problems, but when I try and read
  26. > it back in the resulting object has been garbled, it's attributes changed
  27. > with the occasional garbage character.
  28.  
  29. > Strangely enough, if I try this with an object with no functions, it
  30. > works perfectly.
  31.  
  32. Offhand, I would guess that your object has pointers in it (possibly virtual
  33. pointers).  Pointers, no matter how you look at them, are memory references
  34. and those references are not persistent (they change from invocation to
  35. invocation).  Also, in doing the "block write" that your doing above, you are
  36. not saving anything that the object points to.
  37.  
  38. As far as I've seen, there is no automatic, reliable approach to writing a C++
  39. object to a file (or sending it in a message).  It requires knowing what the
  40. format of the object internally looks like and, possibly, converting this
  41. internal format into a format that is persistent.
  42.  
  43. The only generic, portable approach to doing this that I've seen is what I'll
  44. call "linearization" of an object.  That is, when object wants to write itself
  45. onto a stream (as defined by operator>>), it converts itself into a stream of
  46. bytes that will be recognizable on the other end of the stream (so that
  47. operator<< will understand it).  With these operators defined on every object,
  48. newly derived objects simply worry about their internal structure and call the
  49. appropriate superclass method to handle the rest.  The drawback with this is
  50. that it suggests a Smalltalk approach to creating objects (everything derives
  51. from the central controlling Object).  Naturally, there are a lot of little
  52. "gotchas" in this that must be worked out (like peeking into a stream and
  53. making a guess about what the next object is that's coming out of the stream
  54. so that the appropriate object may be constructed).
  55.  
  56. Comments?
  57. --
  58. ====================================================================
  59. David Masterson                    Consilium, Inc.
  60. (415) 691-6311                    640 Clyde Ct.
  61. uunet!cimshop!davidm                Mtn. View, CA  94043
  62. ====================================================================
  63.