Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!bacchus.pa.dec.com!rust.zso.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!diamond
From: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Newsgroups: comp.lang.c++
Subject: Re: Faulty Ambiguity Detection with Virtual Bases
Message-ID: <1990Nov2.003440.992@tkou02.enet.dec.com>
Date: 2 Nov 90 00:34:40 GMT
References: <54733@brunix.UUCP> <2351@lupine.NCD.COM>
Reply-To: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 41

In article <2351@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
<In article <54733@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes:
<<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):  [deleted]
<
<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?

People can build time bombs no matter what you do.  Programmers who wish to
be safe will disambiguate every use of an inherited component at the point
where it is used, whether or not dismbiguation is necessary (yet).

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

A warning (switchable on or off) might be reasonable.  This would be less
helpful than you imagine because:
<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).
Suppose your A vendor adds a new feature to A which you don't use, and
your B vendor adds a new feature to B with the same name?  Suppose B and
C both come from the second vendor, C uses a feature of B and C uses other
features of A (i.e. the second vendor is also a client of the first vendor),
and the first vendor adds a feature to A with the same name?  Do you wait
for the second vendor to mail you a revised C?  Or do you hope that they
have already (previously unnecessarily) disambiguated all uses of inherited
features, and that you yourself have done the same in your classes?

-- 
Norman Diamond, Nihon DEC    diamond@tkov50.enet.dec.com
                                    (tkou02 is scheduled for demolition)
We steer like a sports car:  I use opinions; the company uses the rack.