NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/cplus/13035

Internet Message Format | 1992-08-29 | 2.9 KB

Path: sparky!uunet!haven.umd.edu!darwin.sura.net!jvnc.net!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!ut-emx!emx.utexas.edu!plyon
From: [e-mail] (Paul Lyon)
Newsgroups: comp.lang.c++
Subject: Re: File I/O using C++ (write/read objects...)
Message-ID: <[e-mail]>
Date: 29 Aug 92 00:31:42 GMT
References: <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Organization: The University of Texas at Austin
Lines: 50
In-reply-to: [e-mail]'s message of 26 Aug 92 20:29:38 GMT


In article <[e-mail]> [e-mail]
(David S. Masterson) writes:

   As far as I've seen, there is no automatic, reliable approach to
   writing a C++
   object to a file (or sending it in a message).  It requires knowing what the
   format of the object internally looks like and, possibly, converting this
   internal format into a format that is persistent.

   The only generic, portable approach to doing this that I've seen is
   what I'll call "linearization" of an object.  That is, when object
   wants to write itself onto a stream (as defined by operator>>), it
   converts itself into a stream of bytes that will be recognizable on
   the other end of the stream (so that operator<< will understand it).
    With these operators defined on every object, newly derived objects
   simply worry about their internal structure and call the appropriate
   superclass method to handle the rest.  The drawback with this is that
   it suggests a Smalltalk approach to creating objects (everything
   derives from the central controlling Object).  Naturally, there are a
   lot of little "gotchas" in this that must be worked out (like peeking
   into a stream and making a guess about what the next object is that's
   coming out of the stream so that the appropriate object may be
   constructed).

   Comments?
   --

These remarks seem sensible enough to me, but I think it worth noting
that a model of how to do this may be found in the NIH class library.
See, in particular, the "OIO" files in the distribution thereof and
the documentation for same. Both may be ftp'd from
wuarchive.wustl.edu, in the directory ~ftp/mirrors2/gnu. What they do
here is both to have a single derivation tree and also to keep a table
of class information that allows each store-to-stream and
read-from-stream method to keep track of contained class objects and
class derivation so that each object of a class in the system can
reliably be written out and recovered in such a way that each class in
the system only needs to worry about the data peculiar to itself in
the process, leaving its base classe object(s) and contained class
object(s) to take care of their own, and so on.  I do not know how
adaptable their approach would be to other contexts, but pondering the
approach taken should at least be informative about what needs to be
done to make this sort of scheme work.

Hope this helps...

Paul Lyon