rfg@NCD.COM (Ron Guilmette) (10/31/90)
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.