Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!devnull!elmer.Berkeley.EDU!kelley From: kelley@mpd.tandem.com (Michael Kelley) Newsgroups: comp.lang.c++ Subject: Re: typeof() and virtuals and overloading, oh my! Message-ID: <157@devnull.mpd.tandem.com> Date: 29 Mar 91 22:52:34 GMT References: <27F23200.6FCE@tct.uucp> <18979@milton.u.washington.edu> <27EF838D.4115@tct.uucp> <19093@milton.u.washington.edu> Sender: news@devnull.mpd.tandem.com Lines: 121 >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. Wait a minute; don't you say (five paragraphs down) that pointers within objects present a real problem? Wouldn't you agree it's in what you call freezing, as well as thawing? (Aside: nifty new terms, Chip.) How is it that you then infer the original poster doesn't understand the situation? Maybe he was posting *in order to understand*, but I'd imagine it doesn't help him when you contradict yourself... > >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. Whoa! It's great that you understand the difference between support for functionality at the language level as opposed to support from a library. Obviously, ADA went too far in trying to do too much as a language. But is it realistic to completely decouple the language features from supporting libraries? Not here, I think. (Just why do you think there is an ANSI-C++ library committee that works *with* the people responsible for the language?) I'll go out on a limb and argue that in order to retrieve/activate/thaw an object, there MUST be a typeof() defined within the language in order to store/pacify/freeze *any* object and it's type. Further, this typeof() must be able to determine equivalence between tags based on class hierarchy, unless you have either (1) dynamic loading or (2) no need for anything but exact type matching between a stored object and the object you use in memory. If you have neither, then yes, you got me there, the semantics of your functions must be very well defined. I think I'm with you in that reading an object back in is still a big hairy mess. I think at a minimum, we'd need a special constructor (defined as part of the language), which just sets up virtual tables, and then calls a conversion routine to map "neutralized" data into some architecture-specific format. As an aside, I don't believe it's possible to make conversion a part of the language (witness pointers and the like). But surely we could agree on conversion routine names a little-better-than-brain-dead linker would know about so that a *standard* library could [de]neutralize *any* object, independent of it's subclasses? In case you're wondering, we use a filter to sweep through object modules and libraries to look for magic cookies generated by a smart cpp, which it uses to build a data structure which encodes and provides access to our type hierarchy. No macros, no nothing, just as long as our superclass is an ancestor, it works great. Given a complete hierarchy description, a deep copy is possible with no programmer intervention... I don't think persistance is a fad that's going to go away -- I think the amount of traffic on the matter backs it up. The time is coming, I think, (those OODBMS people must be chomping at the bit!), when someone will come up with a reasonably-priced persistance package. Then, enough people will use it, and whether a program's state information is determined through persistance or on the fly will be a non-issue -- except that if your program can't do so, or your external format is incompatible with theirs, you may as well just go home. And the other guy's/gal's code will look so much like C++, you won't be able to defend yourself. Bjarne must be both extremely pleased to see so much hoopla over his baby, as well as frightened over all the "evil" plans we all have for it. But frankly, knowing that C++ was expressly designed, in part, to be compatible with ANSI C indicates to me that other such pragmatic goals may in fact be more than acceptable to the "powers that be". > >>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! Ah, ok. "..._is_ a bad design! ... You, as a human...". Thanks for sage words from the human compiler, Chip. Now as I remember, the required "feature" is called dispatching, which was rejected *not* because it's not useful, or indicates a bad design, but because it's too doggone hard to specify in a language, much less to implement in a (fast) compiler which produces (fast and reasonably sized) code. Mike Kelley Tandem Computers, Austin, TX kelley@mpd.tandem.com (512) 244-8830 / Fax (512) 244-8247