Xref: utzoo comp.lang.c++:10155 comp.std.c++:387
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucsd!pacbell.com!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Faulty Ambiguity Detection with Virtual Bases
Message-ID: <2351@lupine.NCD.COM>
Date: 31 Oct 90 09:05:46 GMT
References: <54733@brunix.UUCP>
Followup-To: comp.lang.c++
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 57

In article <54733@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes:
<Normally, C++ doesn't complain about potential ambituity, only ambiguity at
<a point of call.  With MI, for example, if a function is inherited through
<two paths, the function to be called must normally be disambiguated only
<when it is called.  As the ARM puts it (p. 206):
<
<    Only the *use* of a name in an ambiguous way is an error, however;
<    combining classes that contain members with the same name in an
<    inheritance scheme is not an error.

I have always felt that this was a big mistake in the language design.
Why is it ever a good idea to let people build time bombs which just
sit around waiting to go off until somebody first touches them?

I feel that it would be much better to have compilers tell class authors
whenever they have created (unwittingly) the *possibility* of ambiguity.

Now somebody may argue that one might obtain a class A from one source of
code, and a class B from another source, and then one should be able to
write one's own class C, derived from both A and B, and have it pass
compilation in all cases (so that the author of C will not be bothered
unnecessarily with superfluous errors about inherited members of C
which never actually get used bu C's clients).  In my opinion, such an
argument is just bunk.  This is just a way of supporting and reinforcing
laziness on the part of the author of class C (who could easily fix all
conflicts by adding code within C and without touching either A or B).

<But consider the following example, where function foo is inherited through
<two paths in class Bottom:

[... text deleted...]

<AT&T cfront 2.0 and Sun's cfront 2.1 (beta) both give the following error:
<
<    "ambiguity.C", line 16: error: virtual base: ambiguous Middle1::foo()
<                                                 and Middle2::foo()
<
<On the other hand, g++ 1.37 takes it without complaining.  Furthermore, if
<either Middle1 or Middle2 is made a nonvirtual base class, then cfront is
<happy, too, even though the ambiguity remains.
<
<    1.  Does anybody feel this is not an error in cfront?

Yes.  At the very least, cfront should try to be more consistant about
what it defines as erroneous.

<    2.  Can anybody explain to me why it should make a difference whether a
<        base class is virtual or not in the above example?

I certainly can't.  Perhaps the authors of cfront will step forward and
make a statement.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.