From -8162845851858356657 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,db4807a3f0a1e742 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-08-03 15:27:07 PST Newsgroups: comp.std.c++ Path: bga.com!news.sprintlink.net!hookup!swrinde!gatech!europa.eng.gtefsd.com!swiss.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!jjb From: jjb@watson.ibm.com (John Barton) Subject: Re: Multiple inheritance and delete Sender: news@hawnews.watson.ibm.com (NNTP News Poster) Message-ID: Date: Wed, 3 Aug 1994 17:21:23 GMT Disclaimer: This posting represents the poster's views, not necessarily those of IBM. References: <1994Aug02.045000.2253@corona.com> Nntp-Posting-Host: jjb.watson.ibm.com Organization: IBM T.J. Watson Research Center Lines: 45 In article , olaf@cwi.nl (Olaf Weber) writes: |> In article <1994Aug02.045000.2253@corona.com>, pkron@corona.com |> (Peter Kron) writes: [ stuff deleted] |> |> > Non-polymorphic structs (ie, which override inherited, non-virtual |> > member functions) are just as error prone as non-polymorphic |> > classes. |> |> This is an interesting definition of non-polymorphic structs. If I |> understand it correctly, the structs in the example above are not |> non-polymorphic by that measure. |> |> Now, does anybody actually _know_ how much of a problem C++'s ability |> to override non-virtual member functions is? I suspect that code that |> uses that particular construct is very rare indeed. If so, and if my |> interpretation of what Peter Kron means by non-polymorphic is correct, |> then it would seem that we are arguing a non-issue here. |> You are certainly arguing a non-issue: there is no such thing as an override of a non-virtual member function. Names declared in derived classes hide names declared in base classes in the same way that names declared in inner blocks hide names declared in outer blocks. Overriding only occurs for virtual functions. The concept that everything in C++ should be "polymorphic", meaning in this case a the narrow virtual function dispatch version of polymophism, is silly. The only reason to pay for the overhead of building vtables, storing vtable pointers, initializing vtable pointers, calling through vtables, and managing memory through pointers as vtables require is if your application needs to build collections of similar but not identical objects (eg collections of triangles, circles and squares) or if you want to use pure abstract base classes as an object-oriented API mechanism. There are many applications that use static polymorphism via templates. Here identical member function names express commonality and if you want to combine this with inheritance to do data-structure reuse, name hiding is exactly what you need. -- John. John J. Barton jjb@watson.ibm.com (914)784-6645 H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598