In article <CuBpo9.14Gz@hawnews.watson.ibm.com>, jjb@watson.ibm.com (John Barton) writes:
> In article <1994Aug10.114728.17415@lts.sel.alcatel.de>, kocher@lts.sel.alcatel.de (Hartmut Kocher US/ESA 60/1L/2? #5629) writes:
> |> Name domination is a feature that comes into play when you have
> |> virtual base classes and a function can be reached through several
> |> paths.
> |>
> |> This is described in Section 10.1.1 of the ARM (p205). The following
> |> example is a slight variation of this theme that is not covered by
> |> the text in the ARM. Although I think by the spririt of the ARM,
> |> the following is allowed, I'd like to hear the opinion of some
> |> experts. (Maybe, the ARM text could be more precise in the WP.)

[stuff deleted]

> |> Any comments?
>
>   Yes: report compiler bugs to your compiler vendor, not to
> comp.std.c++.  If you are offering unsolicited recommendations, please
> tell us which compilers get it right and which do not.
John,

I report compiler bugs to the vendor. In this case I just wasn't sure
if my interpretation of the ARM is right. Your answer didn't help
in this regard.

But since you asked:
Sun CFront 3.0 and Symantec 7.0 on the Mac got it right.
Metroworks DR3 for PowerPC compiled but called the wrong functions.
GreeHills 1.8.6 on Sun claimed the functions to be ambigious

--
+==============================|==============================+
| Hartmut Kocher               |                              |
| Technical Consultant         | All opinions expressed here  |
| Rational GmbH                | are my own.                  |
| Rosenstrasse 7               |                              |
| 82049 Pullach im Isartal     | I know you guessed it,       |
| Germany                      | but it keeps my lawyer happy.|
| Email: hwk@rational.com      |                              |
+==============================|==============================+

In article <1994Aug10.114728.17415@lts.sel.alcatel.de>, kocher@lts.sel.alcatel.de (Hartmut Kocher US/ESA 60/1L/2? #5629) writes:
|> Name domination is a feature that comes into play when you have
|> virtual base classes and a function can be reached through several
|> paths.
|>
|> This is described in Section 10.1.1 of the ARM (p205). The following
|> example is a slight variation of this theme that is not covered by
|> the text in the ARM. Although I think by the spririt of the ARM,
|> the following is allowed, I'd like to hear the opinion of some
|> experts. (Maybe, the ARM text could be more precise in the WP.)
|>
|> Here's the code:
|>
|> #include <iostream.h>
|>
|> class Base {
|> public:
|>    virtual void f() { cout << "Base" << endl; }
|> };
|>
|> class D1 :  /* virtual */  public Base {   // here's the fun part
|> };
|>
|> class S1 : virtual public D1 {
|> public:
|>    virtual void f() { cout << "S1" << endl; }  // Dominates Base::f
|> };
|>
|> class S2 : virtual public D1 {
|> };
|>
|>
|> class Join : public S1, public S2
|> {
|> };
|>
|> main()
|> {
|>
|>    Join j;
|>    j.f();
|>
|>    Base * b1 = &j;
|>    b1->f();
|>    D1 * d1 = &j;
|>    d1->f();
|>    S1 * s1 = &j;
|>    s1->f();
|>    S2 * s2 = &j;
|>    s2->f();
|>
|>    return 0;
|> }
|>
|> If Base wouldn't exist and f() would be defined in D1, we have the example of
|> the ARM. Now if D1 is publicly derived from Base, all other classes are
|> still derived virtually from D1 and Base::f() should be dominated by S1::f()
|> because all paths going to Base are going through D1. Therefore, all calls to
|> f() should print "S1".
|>
|> I tried a couple of compilers with different results:
|> - One said that calling f() was ambigous.
|> - One compiled it but called Base::f() for b1, d1, and s2.
|> - One did what I expected.
|>
|> If the comment /*... */ is removed (i.e., D1 is virtually derived from Base) all
|> three compilers behave consistently like I expected (i.e., all called S1::f()).
|>
|> Any comments?

  Yes: report compiler bugs to your compiler vendor, not to
comp.std.c++.  If you are offering unsolicited recommendations, please
tell us which compilers get it right and which do not.

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

Name domination is a feature that comes into play when you have
virtual base classes and a function can be reached through several
paths.

This is described in Section 10.1.1 of the ARM (p205). The following
example is a slight variation of this theme that is not covered by
the text in the ARM. Although I think by the spririt of the ARM,
the following is allowed, I'd like to hear the opinion of some
experts. (Maybe, the ARM text could be more precise in the WP.)

Here's the code:

#include <iostream.h>

class Base {
public:
   virtual void f() { cout << "Base" << endl; }
};

class D1 :  /* virtual */  public Base {   // here's the fun part
};

class S1 : virtual public D1 {
public:
   virtual void f() { cout << "S1" << endl; }  // Dominates Base::f
};

class S2 : virtual public D1 {
};


class Join : public S1, public S2
{
};

main()
{

   Join j;
   j.f();

   Base * b1 = &j;
   b1->f();
   D1 * d1 = &j;
   d1->f();
   S1 * s1 = &j;
   s1->f();
   S2 * s2 = &j;
   s2->f();

   return 0;
}

If Base wouldn't exist and f() would be defined in D1, we have the example of
the ARM. Now if D1 is publicly derived from Base, all other classes are
still derived virtually from D1 and Base::f() should be dominated by S1::f()
because all paths going to Base are going through D1. Therefore, all calls to
f() should print "S1".

I tried a couple of compilers with different results:
- One said that calling f() was ambigous.
- One compiled it but called Base::f() for b1, d1, and s2.
- One did what I expected.

If the comment /*... */ is removed (i.e., D1 is virtually derived from Base) all
three compilers behave consistently like I expected (i.e., all called S1::f()).

Any comments?

--
+==============================|==============================+
| Hartmut Kocher               |                              |
| Technical Consultant         | All opinions expressed here  |
| Rational GmbH                | are my own.                  |
| Rosenstrasse 7               |                              |
| 82049 Pullach im Isartal     | I know you guessed it,       |
| Germany                      | but it keeps my lawyer happy.|
| Email: hwk@rational.com      |                              |
+==============================|==============================+