Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!tscs!tct!chip From: chip@tct.com (Chip Salzenberg) Newsgroups: comp.lang.c++ Subject: Re: typeof() and virtuals and overloading, oh my! Message-ID: <27F77834.16D6@tct.com> Date: 1 Apr 91 18:13:08 GMT References: <27EF838D.4115@tct.uucp> <19093@milton.u.washington.edu> <157@devnull.mpd.tandem.com> Organization: Teltronics/TCT, Sarasota, FL Lines: 90 According to kelley@mpd.tandem.com (Michael Kelley): >According to chip@tct.com (Chip Salzenberg): >>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? No, I did not say that. I did say that pointers render impractical the naive approach of "write(fd, p, sizeof(*p))". But since that naive approach is not used by anyone interested in portability, its failure does not bode ill for other freezing methods. >(Aside: nifty new terms, Chip.) I'd like to take credit for them, but I'm sure they've been used before... anyone care to prove me unoriginal? [:-)] >>The language type system is inoperative on dead arrays of bytes. > >Is it realistic to completely decouple the language features from supporting >libraries? Not here, I think. There is no useful distinction to be made between a language feature and a required library function. Consider that ANSI C permits the compiler to recognize standard functions and treat them specially, such as by expanding them inline. After all, if the language system executes a program correctly, do we care if it uses a library routine or a compiler feature for function X? I think not. So the issue of language vs. library is irrelevant to this discussion. >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 its type. Sorry; typeof() is neither necessary nor sufficient. Not necessary: because a virtual freeze_on() function for each type can be written. It's a bit of a pain, yes, but it can be done. Not sufficient: because a simple_minded freeze_on() function that iterates across member variables cannot deal intelligently with pointers and references, especially for recursive data structures. >I think I'm with you in that reading an object back in is still a big >hairy mess. No argument. :-) :-( >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. Nope. Again because of the possibility of recursive data structures and other tricks, thaw_from() *cannot* be written automatically, unless the structures to be frozen and thawed are greatly restricted. Given that fact, it's up to you, the programmer, to use whatever convention suits you. Perhaps a one-argument constructor that takes an "istream &" will do. >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? The flaw in this plan is evident in the next paragraph: >In case you're wondering, we use a filter to sweep through object modules... >No macros, no nothing, just as long as our superclass is an ancestor ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ With a common ancestor, all things are possible. The C++ language, however, is based on a type forest, not a type tree; common ancestors are the exception, not the rule. >Now as I remember, the required "feature" is called dispatching ... My comment about "B::foo(B&)" and "D::foo(D&)" not being the same function is irrelevant to issues of dynamic dispatching. It doesn't matter _how_ you decide to execute "x.foo()". B::foo() and D:foo() implement different functions, and thus should be either non-virtual or distinctly named. -- Chip Salzenberg at Teltronics/TCT , "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre