Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!pdn!tscs!tct!chip
From: chip@tct.uucp (Chip Salzenberg)
Newsgroups: comp.lang.c++
Subject: Re: typeof() and virtuals and overloading, oh my!
Message-ID: <27F23200.6FCE@tct.uucp>
Date: 28 Mar 91 18:12:16 GMT
References: <18979@milton.u.washington.edu> <27EF838D.4115@tct.uucp> <19093@milton.u.washington.edu>
Organization: Teltronics/TCT, Sarasota, FL
Lines: 59

According to jjb@hardy.acs.washington.edu (Jim Black):
>In article <27EF838D.4115@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>>Anything a type tag can do, a virtual function can do ...
>
>Try to snapshot an object, and bring it back to life in a different address
>space.  The virtual function table pointer is meaningless at that point,
>because it points into the wrong address space.  You want some way of 
>knowing the type of the object - SPECIFICALLY TO RESTORE THE VIRTUAL
>FUNCTION TABLE POINTER!  

I think we all agree that object freezing (translation of an object to
dead bytes) is essentially a non-problem, or at least a much simpler
problem than the issue Jim raises, namely, object thawing (translation
of dead bytes to an object).  So I will concentrate on the latter.

Rhetorical question: If an object is just dead bytes frozen in a file
or shared memory segment or whatever, how does the compiler know any
better than the programmer what the real type of the frozen object?

Answer: It hasn't a clue.  The language type system is inoperative on
dead arrays of bytes.  Neither typeof() nor any other type-specific
mechanism can do your work for you here.  You're on your own.

I continue, therefore, to maintain that a compiler-supported typeof()
function would be of little utility, and none for object thawing.

>I want to just snapshot the whole "new"'d range of memory and be able
>to reinstantiate it at a later time ...

What if the members are pointers or contain pointers?  You can't
seriously expect all persistent objects to be pointer-free!  (Talk
about not understanding the situation...)

>>If you want or need to change an argument in an overriding virtual
>>function, then it is obvious that you're not simply providing a new
>>implementation of the _same_ function.  ...  blame your design.
>
>class B {
>    operator <= (B&);
>};
>class D : B { 
>    operator <= (D&);
>};
>
>I dunno, call this bad design, but I don't think so.

Then we must disagree, because to me, this _is_ bad design!

You, as a human, may consider "<=" to be "the same function" in both
cases; but the compiler cannot make that leap.  To the compiler, the
first function implements "less than or equal to a B", and the second
function implements "less than or equal to a D" -- quite different!

Thus they are _not_ two implementations of the _same_ function, and
they should not be given the same name.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
   "All this is conjecture of course, since I *only* post in the nude.
    Nothing comes between me and my t.b.  Nothing."   -- Bill Coderre