Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.c++ Subject: Re: Overloading vs. virtual functions Message-ID: <27CD13BF.64D1@tct.uucp> Date: 28 Feb 91 14:29:17 GMT References: <1991Feb19.051123.5198@gpu.utcs.utoronto.ca> <27C2D4B8.3AD3@tct.uucp> <1991Feb25.201923.14554@gpu.utcs.utoronto.ca> Organization: Teltronics/TCT, Sarasota, FL Lines: 69 According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >In article <27C2D4B8.3AD3@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >Sometimes you must/can be aware of the [compile-time/run-time] seam. In fact, I find it vital to keep ``the seam'' clearly in mind at all times. Perhaps some find this distinction irritating, and wish to forget it. I don't. >You can remove the distinction [between compile-time and run-time binding] >in many cases without removing the control. Take overloading: if I provide >a function that accepts both Date("Feb.25/91") and Date(91, 2, 25) ... I confess that the point of the Date() example escapes me. It describes only compile-time binding (of constructors, I assume, though it hardly matters) and seems irrelevant to virtual functions. >[initializations can be optimized away, if they only use...] >static arguments that have no (derived types AND virtual functions)" Of course. But constant expression folding was state-of-the-art in the 60's, and it has zero relevance to OOP typing issues. >The choice of calling the "real" (Type *x; x->member; Type &y; y.member) >or "formal" (Type x; x.member) (type-associated) function still belongs >to the consuming programmer. And the consuming programmer can always say "d.Base::member()", too, overriding both static and dynamic typing. But I confess that I the relevance of this language feature to a supposed conflict between overloading and virtual functions escapes me. >>>When you mix virtuals and overloading, things get scary ... >>"Well, don't do that, then." >Then C++ is a far less powerful language. I fail to see the weakness implied by this statement. >>I would contend that, once virtual functions have been introduced into >>a class hierarchy, the additional use of overloaded functions is the >>design error to be corrected, not some presumed deficiency in C++. > >So you are saying *never* to overload virtuals ? If so, then that is the >strongest admission I can think of, that the present rules for doing so >are useless. No, no more than I would say *never* to use a goto. What I *am* saying is that the use of an overloaded virtual function likely points out an opportunity to make a class design more regular. In the absence of other considerations, I would suggest that the overloading of the virtual function be subsumed into an overloaded constructor (or non-member function), and that the constructed object (or function return value) be used as an actual parameter of the no-longer-overloaded virtual function. The advantage of this change is that the expansion of the overloaded alternatives requires only one change: an additional constructor or non-member function. An overloaded virtual function, to support an equivalent expansion, would require N additional functions for the N classes that implement the given virtual function. >>The differences between these techniques is a tool, not a flaw. >It is a flaw, not a tool. We must agree to disagree, then. -- Chip Salzenberg at Teltronics/TCT , "It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber (with reference to the upage bug in Interactive UNIX and Everex ESIX)