rme@wdl1.UUCP (Richard M. Emberson) (08/24/88)
Information Please: Soon (six months) we will all have C++ version 2.0 which allows one to use multiple inheritance. I've seen Smalltalk-like single inheritance class trees but I've never seen any discussion concerning what a multiple inheritance class "tree" (actually, acyclic directed graph) should look like, or even what the issues might be. I would appreciate pointers to literature dealing with this subject (or some cogent discussion). Thanks. Richard M. Emberson, Jr.
klee@daisy.UUCP (Ken Lee) (08/27/88)
You might want to read "Multiple Inheritance for C++" by Bjarne
Stroustrup (Proceeding sof the EEUG Spring Conference, Helsinki,
May, 1987).
Multiple inheritance is difficult to implement, but once someone
else has written the compiler, application programming is very easy.
The Stroustrup paper discusses the implementation in C++.
Multiple inheritance has many applications in the graphics world. For
example, your window system may have graphics window, text window, and
scrollable window classes. An application programmer may want to
create a new class with properties from all three. Without multiple
inheritance, this is very messy. Several of the popular user interface
toolkits (e.g., X Toolkit, Andrew Toolkit) have this problem with
single inheritance and can't wait for C++ with multiple inheritance.
Ken Lee
Daisy Systems Corp., Interactive Graphics Tools Dept.
--
uucp: {ames!atari, ucbvax!imagen, nsc, pyramid, sgi, uunet}!daisy!klee
arpanet: daisy!klee@sgi.com or daisy!klee@uunet.com
Don't applaud, just throw money.gnulists@WHEATIES.AI.MIT.EDU (03/28/89)
The rumour went around Georgia Tech that the newest GNU g++ handled multiple inheritance. Where did that rumour come from? I got "g++-1.34.1.tar.Z" from "prep.ai.mit.edu". I use a sun3. Is there even a schetchy list of what is supposed to work in this distribution? Am I overlooking some documentation file? g++.texinfo documents many things well, but seems out of date. For instance, people on the net are discussing special return variables, which are not in g++.texinfo. How did they find out about these? Multiple inheritance isn't mentioned either. What I can intuit from testing and looking at the sources, multiple inheritance works only in the following special case: -- nothing is virtual. -- variables of superclasses are not accessed directly. (i.e., you use member functions only to access your supers). Is this right? Supposed to work? TIA, Henry Strickland <strick@gatech.edu>
eirik@lurch.stanford.edu (Eirik Fuller) (04/26/89)
Since GNU C++ will soon support multiple inheritance, we are seeking C++ code that uses multiple inheritance, for testing the compiler. What we would most like to see is email pointers to free code on internet ftp sites, but failing that email code is ok too. If appropriate, I can post a summary of responses in a week or so. Reply to eirik@lurch.stanford.edu or tiemann@lurch.stanford.edu Thanks, Eirik
daniel@saturn.ucsc.edu (Daniel Edelson) (05/13/89)
++ my comments -- daniel Within <14133@paris.ics.uci.edu> Doug Schmidt <schmidt@siam.ics.uci.edu> asks: >Here's a quick nit. Is the following a legal use of multiple inheritance? ++ I believe not. > As you can see, from one direction class a's member >function `int foo ()' is private for all classes derived from class b. >However, on another path it is public. In class d's constructor, >where `foo ()' is called, foo appears to be derived from classes where >it is both private and public. ++ Private is private, is it not? If the field is private in a base class ++ then it is not available outside of member functions of that class. ++ Your question applys if you use protected instead of private. >Which visibility status prevails? Is this ambiguous, legal, or illegal? >thanks, Doug > class a { > public: > int foo () { printf ("foo\n"); } > }; ++ I changed ``private'' to ``protected'' in classes b and d > class b : public a { > protected: > a::foo; // made protected for all classes derived from class b. > }; > class c : public a { > public: > c () {printf ("c\n");} > }; > class d : public c, public b { > public: > // both public *and* private!! which prevails? > d () { printf ("d\n"); foo (); } > }; ++ My understanding is that if the call is ambiguous it's a ++ syntax error. That might not apply in this case since this is ++ the same function being inherited along two different paths of ++ the DAG. Is this ambiguous, or since it's a single function ++ being referred to twice, is it allowed? If the latter, what ++ happens when it is made virtual? If the former, it can be ++ disambiguated with the :: operator. >| schmidt@ics.uci.edu | ++ Well, I wanted to answer the question but all I've done is ++ ask new ones. daniel edelson daniel@saturn.ucsc.edu
bytor@milton.u.washington.edu (Jill Patterson) (10/19/90)
Hi, I'm trying to figure out some base classes for some graphical
objects I'm working on. This is what I have so far:
class Point
{
public:
virtual short x() {return 0;}
virtual short y() {return 0;}
virtual double wx() {return 0.0;}
virtual double wy() {return 0.0;}
virtual double theta() {return 0.0}
virtual double radius() {return 0.0;}
};
class PhysicalPoint : Point
{
private:
short xCoord;
short yCoord;
public:
PhysicalPoint()
{
xCoord = 0;
yCoord = 0;
}
PhysicalPoint(short x, short y)
{
xCoord = x;
yCoord = y;
}
virtual short x() {return xCoord;}
virtual short y() {return yCoord;}
};
class LogicalPoint : Point
{
private:
double wxCoord;
double wyCoord;
public:
LogicalPoint()
{
wxCoord = 0.0;
wyCoord = 0.0;
}
LogicalPoint(double wx, double wy)
{
wxCoord = wx;
wyCoord = wy;
}
virtual double wx() {return wxCoord;}
virtual double wy() {return wyCoord;}
}
class Rectangle
{
Point *UpLt;
Point *DnRt;
Rectangle(Point *ul, Point *dr)
{
UpLt = ul;
DnRt = dr;
}
}}
Now with the above definitions I should be able to do this (in TC++)
right?
LogicalPoint *lPoint = new LogicalPoint(10.0, 10.0);
LogicalPoint *lPoint2 = new LogicalPoint(30.0, 30.0);
PhysicalPoint *pPoint1 = new PhysicalPoint(10, 10);
PhysicalPoint *pPoint2 = new PhysicalPoint(30, 30);
Rectangle lRect(lPoint1, lPoint2);
Rectangle pRect(pPoint1, pPoint2);
By doing this I should get either a Rectangle with short coordinates or
a Rectangle with double coordinates correct?
But I can't seem to get them to work, HELP!
---------------------
bytor@milton.u.washington.eduilanc@microsoft.UUCP (Ilan CARON) (10/21/90)
In article <9528@milton.u.washington.edu > you write: [I've edited the classes, leaving the important stuff...] > > class Point > { > public: > }; > > class PhysicalPoint : Point > { > public: > PhysicalPoint(short x, short y); > }; > > class LogicalPoint : Point > { > public: > LogicalPoint(); > LogicalPoint(double wx, double wy); > } > > class Rectangle > { > Rectangle(Point *ul, Point *dr); > }} > > > Now with the above definitions I should be able to do this (in TC++) > right? > > LogicalPoint *lPoint = new LogicalPoint(10.0, 10.0); > LogicalPoint *lPoint2 = new LogicalPoint(30.0, 30.0); > > PhysicalPoint *pPoint1 = new PhysicalPoint(10, 10); > PhysicalPoint *pPoint2 = new PhysicalPoint(30, 30); > > Rectangle lRect(lPoint1, lPoint2); > Rectangle pRect(pPoint1, pPoint2); > --------------------- > bytor@milton.u.washington.edu Hi, Well, one of the problems in your definitions (aside from some minor typos) is that Rectangle::Rectangle() is private (that's C++'s default accessibility. One effective way (and in this case unintentional) way of making a class "non-instantiable" by clients is to make its constructors private. Another problem is that LogicalPoint and PhysicalPoint derive *privately* from Point (again this is the default), which I'm sure you did not intend. Use e.g. class LogicalPoint : public Point {...}; The effect of the latter is that a pointer to a LogicalPoint (e.g. lPoint1) can't be cast to a pointer to a Point. Thus the following fails: Rectangle lRect(lPoint1, lPoint2); for two reasons: (1) The constructor Rectangle::Rectangle(Point*, Point*) is private. and (2) LogicalPoint derives privately from Point, hence can't cast lPoint1 and lPoint2 to Point*. Hope this helps. --ilan caron (microsoft!ilanc@beaver.cs.washington.edu)
fargo@iear.arts.rpi.edu (Irwin M. Fargo) (12/06/90)
I just recently learned C++ and am quite confused as to whether C++ was defined to encompass multiple inheritance or not. I read through the book "An Introduction to Object Oriented Programming and C++" by Richard S. Wiener and Lewis J. Pinson. On page 125, they state that C++ allows a derived class to have only one parent (they also mention that Smalltalk allows for multiple inheritance, which confuses me more as I've been using Digitalk's Smalltalk/V 286 for some time and have seen nothing about multiple inheritance). Anyways, a friend of mine is learning C++ now so I decided to browse through his book, "C++ for C Programmers" by Ira Pohl. On pages 192-195, Mr. Pohl writes not only of C++'s ability to do multiple inheritance, but also details how to create derived classes with multiple parents! Both books have made mention of works done by Stroustrop, and I'm going to look into those as I have a very good idea that Mr. Stroustrop had quite a lot to do with the creation of C++. Anyways, what's going on here? Is multiple inheritance part of the original definition? Will it become part of the C++ standard (whenever that comes out) ? Or is this just a discrepancy due to implementation differences? A puzzled C++ novice. Thank you and happy hunting! Actually: Ethan M. Young "If Linus looked like Worf, would you Internet: fargo@iear.arts.rpi.edu try to take his blanket away?" Bitnet (??): usergac0@rpitsmts.bitnet - dorsai@pawl.rpi.edu Disclaimer: Who said what?
fargo@iear.arts.rpi.edu (Irwin M. Fargo) (12/07/90)
With the volume of e-mail replies I received, I felt I should summarize for the other novices. I had read two books about C++, which gave contradictory information concern- ing C++ and its ability to perform multiple inheritance. I asked what was going on. The responses I received said, simply, that multiple inheritance was not part of the original C++ definition by Ellis and Stroustroup, but was added to version 2.0 of the AT&T C++ compiler and has become a de facto feature in all recent implementations. I was also informed that the 2nd edition of Ellis and Stroustroup's "Annotated C++ Reference Manual", which should be out by 2/91, will cover multiple inheritance as well. I had also asked about good references for C++. I was told that E&S's book, although the most comprehensive book on C++, is not the best choice for begin- ning C++ programmers. Some of the books that were suggested include: Lippmann , "The C++ Primer"; Cay Horstmann, "Mastering C++"; Hekmatpour, no title given; and Hansen, "The C++ Answer Book". I'd like to thank everyone who responded and hope this info helps all the other beginners out there. Thank you and happy hunting! Actually: Ethan M. Young "If Linus looked like Worf, would you Internet: fargo@iear.arts.rpi.edu try to take his blanket away?" Bitnet (??): usergac0@rpitsmts.bitnet - dorsai@pawl.rpi.edu Disclaimer: Who said what?
jbuck@galileo.berkeley.edu (Joe Buck) (12/07/90)
In article <_!B^$1$@rpi.edu>, fargo@iear.arts.rpi.edu (Irwin M. Fargo) writes: > The responses I received said, simply, that multiple inheritance was not > part of the original C++ definition by Ellis and Stroustroup, but was added > to version 2.0 of the AT&T C++ compiler and has become a de facto feature > in all recent implementations. I was also informed that the 2nd edition of > Ellis and Stroustroup's "Annotated C++ Reference Manual", which should be out > by 2/91, will cover multiple inheritance as well. GACK!! The CURRENT edition of the ARM covers multiple inheritance. It's in the language now, and documented in all the books you describe. It's no longer a "new feature". -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
horstman@sjsumcs.sjsu.edu (Cay Horstmann) (12/09/90)
In article <_!B^$1$@rpi.edu> fargo@iear.arts.rpi.edu (Irwin M. Fargo) writes: > >I had also asked about good references for C++. I was told that E&S's book, >although the most comprehensive book on C++, is not the best choice for begin- >ning C++ programmers. Some of the books that were suggested include: Lippmann >, "The C++ Primer"; Cay Horstmann, "Mastering C++"; Hekmatpour, no title >given; and Hansen, "The C++ Answer Book". > Sharam Hekmatpour, C++ -- A Guide for C Programmers, Prentice-Hall 1990. This is really a nice book for the competent C programmer. It has a very speedy introduction into C++ (version 2). I like the organization of the material. It is presented in an order that is very natural to the C pro- grammer. Don't expect crazy wisdom about overloaded operator new( size_t, ... ). It is strictly an introduction into the language. Cay
jimad@microsoft.UUCP (Jim ADCOCK) (12/14/90)
In article <KMA^~{@rpi.edu> fargo@iear.arts.rpi.edu (Irwin M. Fargo) writes: |I just recently learned C++ and am quite confused as to whether C++ was defined |to encompass multiple inheritance or not. .... |Both books have made mention of works done by Stroustrop, and I'm going to |look into those as I have a very good idea that Mr. Stroustrop had quite a |lot to do with the creation of C++. Bjarne Stroustr[u]p, with a 'u' actually. Stroustrup is the creator of the C++ language, and remains actively involved in the ANSI-fication effort, and occasionally posts to these notes streams and BIX, among other forums. |Anyways, what's going on here? Is multiple inheritance part of the original |definition? No, multiple inheritence was added at the first major revision. For some time the AT&T "cfront" implementation of C++ was the defacto definition of the language, and people got in the habit of trying to describe approximately what functionality other compilers supported in terms of the AT&T releases. Many authors of C++ books also use this informal numbering scheme. So a book corresponding to the 1.0 release is as old as they come. A book talking about 2.1 releases is as new as they come. You should try to read books that at least claim they are describing the "2.0" version of the language, since the language changed considerable between "1.2" and "2.0." Likewise, you should check that your compiler at least claims being "2.0" "compatible." Over the last couple of years, many authors with little experience in C++ rushed books to print, so you need to be careful picking your C++ texts. I am happy to say the C++ books I've seen published most recently [IE "1991" publishing dates] seem to be improving, and are from more credible authors -- so maybe publishing houses are beginning to recognize they can't get away with publishing anything about C++ anymore. Stroustrup has two books out. The first one "The C++ Programming Language" corresponds to about the 1.1 ? version of the language, so I only use that text as a historical reference -- until it gets updated to the 2.1 [3.0???] version of the language -- which might happen sometime soon, I'd hope? He has a much more recent and formal text: "The Annotated C++ Reference Manual" [by Ellis and Stroustrup] that is being used as the starting point for the C++ standardization effort, so this is a good, but difficult text to have, if one wants to know the intimate details of the language. Most C++ programmers have settled on Lippman "A C++ Primer" for a less formal text that pretty accurately describes the features of the 2.0 version of the language. But get both. |Will it become part of the C++ standard (whenever that comes |out) ? I believe so, yes. There are some vocal critics of multiple inheritence, but I believe they are in the minority. |Or is this just a discrepancy due to implementation differences? No, this is just the difference between the behavior of past releases verses today's releases. Also, templates [parameterized types] and exceptions have been voted "in" the standard by the standardization committee, so when one reads "experimental" disclaimers in current texts, one should rest assured that these features will become "standard" compiler offerings over the next couple of years.
jimad@microsoft.UUCP (Jim ADCOCK) (12/18/90)
In article <39936@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: |In article <_!B^$1$@rpi.edu>, fargo@iear.arts.rpi.edu (Irwin M. Fargo) writes: |> The responses I received said, simply, that multiple inheritance was not |> part of the original C++ definition by Ellis and Stroustroup, but was added |> to version 2.0 of the AT&T C++ compiler and has become a de facto feature |> in all recent implementations. I was also informed that the 2nd edition of |> Ellis and Stroustroup's "Annotated C++ Reference Manual", which should be out |> by 2/91, will cover multiple inheritance as well. | |GACK!! The CURRENT edition of the ARM covers multiple inheritance. |It's in the language now, and documented in all the books you describe. |It's no longer a "new feature". Can someone in the know verify that it is indeed the second version of "The Annotated C++ Reference Manual" that is coming out in Feb, or per chance, is it the long awaited updated version of Stroustrup's original book "The C++ Programming Language" that is coming out then? [It is "The C++ Programming Language" that lacks coverage of MI]