Paragraph 3 of section 10.1 (page 10-2) of the draft standard
specifically declares the following construct to be well-formed
(irrelevant lines omitted):

class L { public int next; /*   */ };
class A : public L { /*    */  };
class D : public A, public L { void f();  /*   */ }; // well-formed

Somehow, I find it inconceivable that the standards committee
would choose to specifically allow a class like class D above
without providing for its proper use.

Current C++ compilers seem to have problems with such a class.

In view of this does anyone have the following information,
which I cannot seem to find in the draft standard?

What is the proper syntax for unambiguously referring to member
of the direct copy of the common base L? L::next is ambiguous
according to most compilers.

What is the proper syntax to unambiguously convert a pointer
(or reference) to the derived class (D) to a pointer (or reference)
to the direct copy of the common bas (L)?
--
** The Klingons' favorite food was named by the first earthling to see it **
David Sachs - Fermilab, MSSG MS369 - P. O. Box 500 - Batavia, IL 60510
Voice: 1 630 840 3942      Department Fax: 1 630 840 3785
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 488@fsui02.fnal.gov, b91926@fsui02.fnal.gov (David Sachs) writes:
>Paragraph 3 of section 10.1 (page 10-2) of the draft standard
>specifically declares the following construct to be well-formed
>(irrelevant lines omitted):
>
>class L { public int next; /*   */ };
>class A : public L { /*    */  };
>class D : public A, public L { void f();  /*   */ }; // well-formed
>
>Somehow, I find it inconceivable that the standards committee
>would choose to specifically allow a class like class D above
>without providing for its proper use.

See below.

>What is the proper syntax for unambiguously referring to member
>of the direct copy of the common base L? L::next is ambiguous
>according to most compilers.
>
>What is the proper syntax to unambiguously convert a pointer
>(or reference) to the derived class (D) to a pointer (or reference)
>to the direct copy of the common bas (L)?

You can't do it. If you want to distinguish the two copies, you need a
different organization. Example:
 class B : public L { }; // B has no members
 class D : public A, public B { ... }; // D members as above
Now you can refer to B::L or A::L unambiguously, as well as B::next
and A::next.

Now I'll answer the "why" part of the question.

The C++ language rules tend to allow potential ambiguity and disallow
only actual ambiguity. Disallowing potential ambiguity is judged too
paternalistic.

In addition, you have to allow many kinds of potential rule violations in
templates, and complain only if the rules are actually violated. Suppose
we have a template class
 template< class T1, class T2 >
  class U : public T2 { ... };
We allow intantiation of U even when T2 is a base class of T1, as long
as no ambiguous reference actually occurs in code that gets used.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

comeau@panix.com (Greg Comeau) writes:

...

>Just in case you do not know, are you aware of virtual inheritance?

>Anyway, to what I _think_ are the issues you are raising:
>You need to add another class to this example to "wrap" B1,
>then C can tell which B1::i is being looked at.

I am quite aware that you can nicely disambiguate everything by
adding a dummy intermediate class, and that a similar class where
all the "copies" of the same base are virtual has genuine utility.

My main question is this:

Why should a class with multiple distinct copies of the same base,
including a direct copy, be EXPLICITLY declared to be well formed,
without any way to unambiguously refer to the direct copy of the
base?

Every draft I have seen of the C++ standard has this hole. The
standards committee should either make such a class ill formed,
or provide a mehtod for unambiguous access.  The simplest way would
be to require that in an analagous way to the behavior of class
members, a direct base class hides indirect copies of the same base.
--
** The Klingons' favorite food was named by the first earthling to see it **
David Sachs - Fermilab, MSSG MS369 - P. O. Box 500 - Batavia, IL 60510
Voice: 1 630 840 3942      Deparment Fax: 1 630 840 3785
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5auci4$k0d@fsui02.fnal.gov> sachs@FNAL.GOV writes:
>If a class has two copies of a base class. e.g.
>
>struct B1 { int i; };
>
>struct B2 : B1 { int j; };
>
>struct C : B1, B2 { int k; };
>
>1) What is the proper syntax to unambiguously convert a pointer
>(or reference) to the class, to a pointer (or reference) to the
>direct copy of the duplicated base?
>
>2) What is the proper systax to unambiguously refer to a member
>of the direct copy of the duplicated base?
>
>The draft standard I have seen, EXPLICITLY allows for the creation
>of such a class, but all wording referring to multiple occurrances
>of the same base class seems to cover only the case where all the
>copies are indirect.
>
>Has the standards committee addressed this issue?

Just in case you do not know, are you aware of virtual inheritance?

Anyway, to what I _think_ are the issues you are raising:
You need to add another class to this example to "wrap" B1,
then C can tell which B1::i is being looked at.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

If a class has two copies of a base class. e.g.

struct B1 { int i; };

struct B2 : B1 { int j; };

struct C : B1, B2 { int k; };

1) What is the proper syntax to unambiguously convert a pointer
(or reference) to the class, to a pointer (or reference) to the
direct copy of the duplicated base?

2) What is the proper systax to unambiguously refer to a member
of the direct copy of the duplicated base?

The draft standard I have seen, EXPLICITLY allows for the creation
of such a class, but all wording referring to multiple occurrances
of the same base class seems to cover only the case where all the
copies are indirect.

Has the standards committee addressed this issue?
--
** The Klingons' favorite food was named by the first earthling to see it **
David Sachs - Fermilab, MSSG MS369 - P. O. Box 500 - Batavia, IL 60510
Voice: 1 630 840 3942      Deparment Fax: 1 630 840 3785


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]