🚀 go-pugleaf

In article <luc.rogge.14.00BD3C10@rol.eunet.be>,
   luc.rogge@rol.eunet.be (Luc Rogge) wrote:
>I wonder: does the draft standard talk about selecting
>inherited members in the case of multiple inheritance?

Yes: 'Say what you mean, mean what you say.'  Use scope resolution (as you go
on to do, examples elided).  That's the second-best way; the best way is to
avoid the problem (see below).

>In the case of multiple inheritance, it is possible that more than one member
>is available with the same signature. In my Visual C++ 1.52 implementation,
>there are two ways to handle ambiguities:

I'm not convinced that the dominance rule means what you might think it does.
It's meant for the case of 'diamond inheritance', inheritance from two
parents with a common (often virtual) ancestor.  Your examples don't show
this, and so you seem to be talking about using two unrelated bases that
happen to have similar member functions, which is something best handled by
fixing the design or using scope resolution appropriately.

[Aside: Visual C++ 1.x isn't a very standards-conforming compiler (omits a lot
of stuff and gets some of what it does implement wrong).  It's not a good
testbed for exploring things like this.]

>So far, it's okay, but they are two other cases where I don't want or can use
>:: to avoid ambiguity.
>
>3) I am designer of class Z and I don't want users of my class losing their
>time to guess which foo() to call (an maybe selecting the wrong one).

When used at all, the scope resolution probably should never have to appear in
user code; your class's members should 'say what they mean, and mean what they
say' even if it means providing new names (e.g. Derived::base1_f() {
Base1::f() }, Derived::base2_f() { Base2::f() }, though you'd probably name
them something that's more meaningful to the user).  Maybe this is what you
mean by "trivial functions" below, but they can be a sign that the design is
sick.  [BTW, this illustrates some of the problems with (over?)using public
inheritance for code reuse.]

>4) foo may be a virtual function; in the case of a late binding, there is no
>way to select the right foo (It shouldn't even compile successfully)

To quote Stroustrup (D&E page 263): "The dominance rule is necessary for
virtual functions -- since is _is_ the rule for which function should be
invoked for a virtual call [...]"

>SO: the only reasonable solution is to make what I call trivial overloadings
>to avoid ambiguity. In one of my designs with a virtual function defined in a
>base class inherited by many sub-classes thru multiple inheritance, such
>trivial functions exceed 60% of my classes source code, obfuscating it.

Sounds like something redesign can fix, but I'm not completely sure what you
mean here.  If you are using independent bases, avoid the problem by using
different names (remember that only using different types can make the hiding
rule your enemy if you override any of the overloaded-but-in-different-bases
functions -- see Cline's FAQ book, under FAQs 140-143).  Is this what you
meant?

Herb


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]