From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!o13g2000cwo.googlegroups.com!not-for-mail From: "Jerry Coffin" Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 23 Mar 2005 20:46:43 -0800 Organization: http://groups.google.com Message-ID: <1111639603.409703.164900@o13g2000cwo.googlegroups.com> References: <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <1110329098.642196@athnrd02> <1110361741.551255@athnrd02> <422edaec$0$26554$9b4e6d93@newsread4.arcor-online.net> <1111464133.508323@athnrd02> <1111508368.393411.6450@z14g2000cwz.googlegroups.com> <1111522653.164049@athnrd02> <9Gi0e.815$FN4.52@newssvr21.news.prodigy.com> <3aenojF67lvh9U1@individual.net> <1111632898.684805@athnrd02> <3aepldF5nu8a5U1@individual.net> NNTP-Posting-Host: 68.64.130.76 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1111639608 13572 127.0.0.1 (24 Mar 2005 04:46:48 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 24 Mar 2005 04:46:48 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: o13g2000cwo.googlegroups.com; posting-host=68.64.130.76; posting-account=mZiOqwwAAAC5YZsJDHJLeReHGPXV5ENp Xref: g2news1.google.com comp.lang.ada:9889 comp.lang.c++:46997 comp.realtime:1669 comp.software-eng:5275 Date: 2005-03-23T20:46:43-08:00 List-Id: Wes Groleau wrote: [ ... ] > Class Wagon has method Draw. > Class Picture has method Draw. > > If you multiply inherit to make > Class Picture_Of_A_Wagon, what does the method Draw do? In C++ the result would be simple: attempting to call Draw without qualification would cause an error due to ambiguity. Note that the mere existence of the situation doesn't lead to an ambiguity or a compiler error -- only when/if you attempt to use the name without qualification does the error arise. This ambiguity would typically be resolved by qualifying the name (i.e. explicitly calling Wagon::Draw() or Picture::Draw()). If you think it makes sense for the derived class to normally call one instead of the other, a using declaration or a forwarding function can provide that. For example, if we wanted the derived Draw to resolve to Picture::Draw, here's how it looks with a using declaration: #include struct Picture { virtual void Draw() { std::cout << "Drawing Picture"; } }; struct Wagon { virtual void Draw() { std::cout << "Drawing Wagon"; } }; struct Picture_Of_A_Wagon : Wagon, Picture { using Picture::Draw; }; For explicit forwarding you'd do this instead: struct Picture_Of_A_Wagon : Wagon, Picture { void Draw() { Picture::Draw(); } }; Of course, in well-written code, you just wouldn't do anything like this at all -- a picture of a wagon is NOT a wagon, and does not satisfy the Liskov Substitution Principle, so having Picture_Of_A_Wagon derive (publicly) from Wagon is just plain wrong. For better or worse, however, compilers (at least for C++) aren't quite smart enough to recognize such problems yet, so it would be up to a person to point out that the code above is broken beyond repair. Multiple inheritance can make sense, but should be restricted to situations where a derived object really can be substituted for either (or any) of the base types. Examples would be having an object with a particular function made from a particular material: class piece_of_aluminium { int alloy; std::string heat_treatment; std::string hardness; int density; }; class pipe{ int diameter; int wall_thickness; int length; }; class aluminium_pipe : public piece_of_aluminium, public pipe { }; Now we have a perfectly reasonable situation: an aluminium pipe that can be treated as either a piece of aluminium or as a pipe. Unfortunately, right now I can't think of a name that would really make good sense in both base classes, so we don't have a potential ambiguity. -- Later, Jerry. The universe is a figment of its own imagination.