In article <3s1ssd$943@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) says:
>
>In article 8009@news.cs.indiana.edu, "Jon Rossie" <jrossie@cs.indiana.edu> writes:
>>/*
>>  Jon Rossie, jrossie@cs.indiana.edu
>>
>>  Ambiguity in vtbls: we force the compiler to decide between two
>>  (ambiguous) definitions of "h" in defining the vtbl for "C".
>> ...
>>  QUESTION: is the semantics of this code specified?
>>*/
>>
>>#include <stdio.h>
>>
>>class A {
>>public:
>>    ...
>>    virtual int h(int y){ return y + y; }
>>};
>>
>>class B {
>>public:
>>    ...
>>    virtual int h(int y){ return y * y; }
>>};
>>
>>class C: public A, public B {
>>public:
>>    ... // h(int) not declared here
>>};
>
>The draft standard, in section 10.3, says a program is ill-formed if
>there is no unique final overrider for a base-class virtual function,
>and paragraph 10 has an example similar to this. The draft does not
>say that no diagnostic is required, so the program must be diagnosed as
>invalid by the compiler.
>
>That is, the program is invalid whether or not the ambiguous function
>is ever called.
>

 Whoops, that's a bit of a hasty reading, Steve. There's no virtual
base involved here.
 A::h is its own final overrider, and B::h is its own final
overrider. Each is unique, so the class is well-formed. An attempt to call
h with a pointer or reference to a C is ill-formed because it is
ambiguous: there are two h's that could be called. But the class itself
is perfectly proper.
 -- Pete

/*
  Jon Rossie, jrossie@cs.indiana.edu

  Ambiguity in vtbls: we force the compiler to decide between two
  (ambiguous) definitions of "h" in defining the vtbl for "C".  Static
  analysis cannot be expected to determine whether or not that vtbl entry
  will ever be dynamically used in the code, so no compiler error can be
  given.  Unfortunately (my perspective), there is no run-time error
  either.  Rather, the behavior seems to indicate that the static "h" is
  being run, since the value is dependent on the current cast.

  I have studied both the ARM and the Working Papers (28 April, 1995), and
  can find nothing that addresses this issue.  Yet the same result is given
  by numerous compilers.

  QUESTION: is the semantics of this code specified?  If so, are the
  behaviors following the specification?  If so, what is the rationale?
  Would it be more sensible for the compiler to store a value in the vtbl
  that would give a meaningful run time error, or are run-time errors
  anathema to a C++ compiler?

  PS: apologies for the use of printf; old habits die hard.
*/

#include <stdio.h>

class A {
public:
    virtual void f(int x){ printf("A::f [%d] h[%d]\n", x, h(x)); }
    virtual int h(int y){ return y + y; }
};

class B {
public:
    virtual void g(int x){ printf("B::g [%d] h[%d]\n", x, h(x)); }
    virtual int h(int y){ return y * y; }
};

class C: public A, public B {
public:
    virtual void k(int x){ this->f(x); this->g(x); }
};


void main (void)
{
    A ai;
    B bi;
    C ci;

    ai.f(12);
    bi.g(12);
    ci.k(12);
    //  printf("ambiguous? [%d]\n", ci.h(12));
    // Yes, that would be ambiguous.
}

/*
moose:examples CC amb.C
CC  amb.C:
cc  -L/usr/local/lib/CC   amb.c -lC
moose:examples a.out
A::f [12] h[24]
B::g [12] h[144]
A::f [12] h[24]
B::g [12] h[144]
*/

In article 8009@news.cs.indiana.edu, "Jon Rossie" <jrossie@cs.indiana.edu> writes:
>/*
>  Jon Rossie, jrossie@cs.indiana.edu
>
>  Ambiguity in vtbls: we force the compiler to decide between two
>  (ambiguous) definitions of "h" in defining the vtbl for "C".
> ...
>  QUESTION: is the semantics of this code specified?
>*/
>
>#include <stdio.h>
>
>class A {
>public:
>    ...
>    virtual int h(int y){ return y + y; }
>};
>
>class B {
>public:
>    ...
>    virtual int h(int y){ return y * y; }
>};
>
>class C: public A, public B {
>public:
>    ... // h(int) not declared here
>};

The draft standard, in section 10.3, says a program is ill-formed if
there is no unique final overrider for a base-class virtual function,
and paragraph 10 has an example similar to this. The draft does not
say that no diagnostic is required, so the program must be diagnosed as
invalid by the compiler.

That is, the program is invalid whether or not the ambiguous function
is ever called.

---
Steve Clamage, stephen.clamage@eng.sun.com