Topic: RTTI and persistence


Author: shap@xanadu.com (Jonathan Shapiro)
Date: Thu, 19 Mar 92 09:57:40 GMT
Raw View
In article <1992Mar4.045829.8156@sophists.com> lewis@sophists.com (Lewis Pringle) writes:
>I did have one qualm however. That had to do with persistence. It seems to me
>one of the more obvious uses of such a facility is in implemeting persistence
>of C++ objects genericly within the C++ language, and aided by it (as opposed
>to using some pre-pre-processor to generate metaclass info).
>
>One might hope that RTTI
>would come to the rescue here, and you could just write the typeid. The
>way that it is defined however, you cannot do this (portably, or even so it
>worked across relinks). Instead, of course, you could use a string
>representation of the class name.

Well, it's much worse than that.  The typeid name generation rule
would have to be universally agreed across C++ implementations, and
you'ld need to explain how to generated the type strings in the face
of templates...


Jonathan Shapiro




Author: cimshop!davidm@uunet.UU.NET (David S. Masterson)
Date: 20 Mar 92 18:29:46 GMT
Raw View
>>>>> On 19 Mar 92 09:57:40 GMT, shap@xanadu.com (Jonathan Shapiro) said:

> In article <1992Mar4.045829.8156@sophists.com> lewis@sophists.com (Lewis
> Pringle) writes:

>>I did have one qualm however. That had to do with persistence. It seems to
>>me one of the more obvious uses of such a facility is in implemeting
>>persistence of C++ objects genericly within the C++ language, and aided by
>>it (as opposed to using some pre-pre-processor to generate metaclass info).

>>One might hope that RTTI would come to the rescue here, and you could just
>>write the typeid. The way that it is defined however, you cannot do this
>>(portably, or even so it worked across relinks). Instead, of course, you
>>could use a string representation of the class name.

> Well, it's much worse than that.  The typeid name generation rule would have
> to be universally agreed across C++ implementations, and you'ld need to
> explain how to generated the type strings in the face of templates...

So?  Is this not a worthwhile goal?  I hope that the ANSI-C++ committee is
addressing the notion of the persistence of C++ objects so that OODBMSs could
work in concert with the language rather than requiring some special interface
on top of the language.  Anyone on the committee care to comment about what
direction (if any) the committee is looking for persistence of C++ objects?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"Posting to alt.flame has nothing to do with writing flames."
-- Patricia O Tuama (rissa@attctc.Dallas.TX.US)




Author: lewis@sophists.com (Lewis Pringle)
Date: Wed, 4 Mar 1992 04:58:29 GMT
Raw View
I just read the BS article (no offence intended) in the latest C++ report
about RTTI (Run Time Type Indentification). Not surprisingly, it was another
example of his thorough, thoughtful, and parsimonious design. I enjoyed
reading it.

I did have one qualm however. That had to do with persistence. It seems to me
one of the more obvious uses of such a facility is in implemeting persistence
of C++ objects genericly within the C++ language, and aided by it (as opposed
to using some pre-pre-processor to generate metaclass info).

Let me outline a common approach, and its pitfalls. One defines a class
Persistent, which can be mixed in with read and write methods.
 class Persistent {
  public:
   void DoWrite (ostream&);

   static Persistent* GetNextObj (istream&);

  protected:
   virtual void read (istream&) = Nil;
   virtual void write (ostream&) = Nil;
 };

You subclass Persistent and override the read/write methods as appropriate
(writing your fields in some format you can read back). This has long worked
straight-forwardly. The points where I might hope the RTTI proposal might begin
helping are in implemeting DoWrite (no relation to Dudly) and GetNextObj ().

Do make these work, you must write some tag to identify the dynamic subtype
of "this" - in other words the actual type of the object. (There are a host
of ways of doing this in Current C++ - but they involve error-prone, and
anoying bookkeeping on the part of subclassers). One might hope that RTTI
would come to the rescue here, and you could just write the typeid. The
way that it is defined however, you cannot do this (portably, or even so it
worked across relinks). Instead, of course, you could use a string
representation of the class name. This could be used as a portable
type id for writing out, had it not been for one of BS's laudable economies
alluded to above. He prohibits making types from Strings!

void Persistent::DoWrite (ostream& out)
{
 // The interesting question is how better to define MY_TYPE_ID???
 const char* MY_TYPE_ID = typeid (this).name ();
 out << MY_TYPE_ID;
 write (out);
}

In reading from the stream in GetNextObj (), you read the type string back, and
have no way to construct an object of that type!

void Persistent::GetNextObj (istream& in)
{
 const size_t kReallyBigBufferSize = 7; // big enuf
       // for HPUX sendmail!
 char name[kReallyBigBufferSize+1];
 in >> name;

 // Now we could do a big if/then/else skip chain with current
 // technology, or some dictionary lookup mapping strings to
 // proc ptrs that would build the right class, but that requires
 // either a seperate pre-processor to generate that mapping table,
 // or programmer care and cooperation to properly maintain it.
 //
 // Instead, would it be nice to say:

 Persistent* result = new name_to_type (name) ();
 result->read (in);
 return (result);
}

I realize that such a name_to_type or similar functionality would present
some problems to the compiler implementor, and if there is interest in
this line of reasoning, I can expand further on how they might be addressed,
but I've blathered on long enuf...

Does someone else have a better solution - does Bjarne's new RTTI really
already have the power to do what I want? Inquiring minds wanna know, and
so do I.


    Lewis.


PS: Notice- only 80 columns...