Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!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: <27FA1D8B.50C3@tct.com> Date: 3 Apr 91 18:23:06 GMT References: <19093@milton.u.washington.edu> <157@devnull.mpd.tandem.com> <162@devnull.mpd.tandem.com> Organization: Teltronics/TCT, Sarasota, FL Lines: 67 According to kelley@mpd.tandem.com (Michael Kelley): >In article <27F77834.16D6@tct.com>, chip@tct.com (Chip Salzenberg) writes: >> There is no useful distinction to be made between a language feature >> and a required library function. > >Yes, Chip, there is a distinction. If it's in the language, it (should be/is) >portable. If it's not, you can only hope it's portable. You missed the word "required", as in "required library function". I stand by my quoted statement. >> 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. > >True, provided *you* implement the class. What happens when you get a class >library from vendor X ... This kind of problem is why I expect attempts at distribution of binary-only C++ classes to have, at best, limited success. C++ requires _everything_ about a class to be in one place, namely, the class definition. In particular, all member functions must be declared there. Forbidding users to change the class definitions is too tight a straightjacket for me to impose on them. (Remember that, in current C++ implementations, adding virtual functions requires the recompilation of all constructors.) >> 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. > >Rather than tightening up the language, as is done with one OODBMS I've >seen, I'd like to write static encoders/decoders for my class variables, >and let "someone else" who understands hierarchy call them as needed. I would appreciate more detail on this proposal before making further comment. Please describe a possible implementation based on G++ or cfront. >But if we don't all do it the same way, we're not going to be able to >leverage off of each other's work. We'll have a forest of objects that >can't talk to each other. I believe that the tree forest of C++ makes type incompatibility, or the "can't talk to each other" phenomenon, inevitable. >What matters is that to invoke the right "x.foo()", I don't have to know >what type "x" is; but, to invoke the "x.foo(y)" I want, *I've* got to tell >the compiler what type "y" really refers to ... Understood. >Again, I realize this may be an intractable problem within C++, but to >write off requests for such functionality as evidence of bad design is >a serious mistake. To paraphrase The Tao Of Programming: A good design finds the simplest harmony between idea and language. In ARM C++, having two virtual functions with the same name but different parameters _is_ a bad design. In ANSI C++, that may not be true any more; but I don't have an ANSI compiler yet. Do you? :-) -- Chip Salzenberg , Brand X Industries Custodial, Refurbishing and Containment Service When You Never, Ever Want To See It Again [tm]