From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: run-time type checking, freezing, and thawing
Organization: netmbx, Berlin, Germany
Date: Fri, 31 Jul 1992 12:49:56 GMT

chip@tct.com (Chip Salzenberg) writes:

>According to jrobie@netmbx.netmbx.de (Jonathan Robie):
>>
>>RTTI is needed to properly freeze a C++ object into a "dead array of
>>bytes" ...

>Virtual functions are sufficient for freezing.

Somebody out there is not listening.  When I say "necessary" I do not
mean that it is impossible for an application programmer to write lots
of code that I could use to do a task.  I simply mean that this info is
not out there unless the compiler or the application programmer supplies it.
Since the compiler has the info and then throws it away I would rather get
it from the compiler, and information gotten from the compiler is also more
likely to be correct...

>>... and to turn a "dead array of bytes" into a C++ object.

>RTTI is of zero relevance to thawing.  It doesn't make this code work:

>    int i;
>    char *buf;
>    read(fd, &i, sizeof(int));
>    buf = new char[i];
>    read(fd, buf, i);
>    XXX *foo = thaw_arbitrary_object(buf, i);

Good thing, too!  Would you *want* it to make that code work? :->
It *does*, however, make this code work:

	PersonAllSet.Get(pPerson);

That is the code to read the next person out of the Person AllSet in
a database.  It works properly regardless of the derived type of the
person (plumber, presidential candidate, gigolo, software developer...)
and restores the object which was originally stored.  Note that the
actual offsets of an object in memory may vary from one executable to
another, so you have to find the location and type of the data members
at run time.

This *can* be done using virtual functions, two for every single data
member in the class (one to get the member, one to set it), plus an
additional member function to identify the parent of the class.  But
these virtual functions make all the data members of the object accessible
in the whole program, and therefore break encapsulation!  You *do* want
private and protected members to be stored in the database without making
them publically accessible, don't you??

If these members are accessed only through run time type identification
then encapsulation and data hiding are preserved *except* for those
functions which use run time type identification.

If virtual functions are written then you have opened your objects
up to everybody.  This is true whether the programmer must write all
these functions (ugh!) or a precompiler does the work (ugh! -- how many
precompilers do we want to replace the information thrown away by the
compiler!).  Of course, you could make all these functions private and
make yourself a friend of each class.  Maybe two or three other libraries
will want to do the same, and maybe their naming conventions will clash,
the signatures of the member functions will be incompatible, the precompilers
will be incompaible with each other...

>>It is also needed to follow references among objects in RAM.

>I can do that without RTTI right now.

An object oriented database or other general purpose tool which does not
know your data types can not.  This was the context of my previous message.
If you want the database to store, retrieve, or query a network of objects
then it needs access to run time type identification.

>>RTTI and persistence are related enough that all of the major C++
>>database systems use precompilers to get at it.

>The mere fact that RTTI can be used for freezing proves neither (1)
>that it is necessary for freezing, nor (2) that it is useful -- much
>less necessary -- for thawing.

No, but the fact that nobody seems to have done it successfully without it
might mean something, given that nobody writes a precompiler if they have
a choice.


Jonathan

======================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)

The opinions expressed in this message are not necessarily those
of my employer, but they should be yours.



-- 
Jonathan

===========================================================================