Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!uwm.edu!ogicse!milton!hardy!jjb
From: jjb@hardy.u.washington.edu (Jim Black)
Newsgroups: comp.lang.c++
Subject: Re: Seeking critique(s) of C++
Message-ID: <19093@milton.u.washington.edu>
Date: 27 Mar 91 08:02:08 GMT
References: <633@taumet.com> <MIKEG.91Mar24104126@c3.c3.lanl.gov> <18979@milton.u.washington.edu> <27EF838D.4115@tct.uucp>
Sender: news@milton.u.washington.edu
Reply-To: jjb@hardy.acs.washington.edu (Jim Black)
Organization: University of Washington, Seattle
Lines: 57

In article <27EF838D.4115@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to black@blake.u.washington.edu (Jim Black):
>>Also I find it's lack of support for type-tags awkward...
>
>Anything a type tag can do, a virtual function can do; in fact, most
>implementation of type tags would simply be compiler-generated virtual
>functions.  A compiler implementation would be of little utility, and
>its lack is not a serious defect in the language.

You say this all the time Chip.  Others have tried to explain to you the
problems encountered with persistent types here, and you don't seem to get it.  

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!  

Some current solutions to this problem, like that in the nihcl library, 
require every new class derived from Object to recurse to it's bases to 
store, call it's members to store, and store its own state.  
It's a mess, it's inefficient, and it's too much work.
I want to just snapshot the whole "new"'d range of memory and be able
to reinstantiate it at a later time - to do that I have to build
type tags on top of the language, and this is more awkward than if 
they were provided.

>>... and the fact that all virtual functions must take the same base-class
>>argument types is awkward too (instead of more specialized versions of the
>>same arguments, for example).
>
>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.  So if this restriction appears
>to be a problem, blame your design.

class B {
    operator <= (B&);
};
class D : B { 
    operator <= (D&);
};

I dunno, call this bad design, but I don't think so.  Right now, class
D must instead code :
class D : B {
    operator <= (B&);
};
and typecheck the parameter to a D& (or blindly cast and damn the torpedos).
If class D is going to typecheck the argument, we're back to implementing 
typetags on top of the language.  Anyway, in many cases, Class D WANTS B's 
implementation (the virtual function table mechanism) to call 
D::operator<=  --  ie, D is simply derived from B, a specialization,
and what worked for B's will work for D's - provided they're type-consistent.
You can use templates to achieve this today, at the cost of losing
plug-and-play over some abstract base.  Sometimes that's okay, sometimes
it's unacceptable.