"Michael Joseph Dalpee" <mjdalpee@wizardsoftware.com> writes:

>Hi,

>I have run into a compilation problem trying to use repeated subobjects.  I
>have compiled the code below on VC++5.0 and Digital Unix 5.5, and although
>neither is happy with it, they give different reasons:

>class A
> {
>public:
> void
> Fa(){}
>};


>class B : A
> {
>public:
> void
> Fb(){Fa();}
>};

>class C : B, A
> {
>public:
> void
> Fc(){Fa();}
>};

>VC gives the following error:
>error C2584: 'C' : direct base 'A' is inaccessible; already a base of 'B'

>While DU complains that the call to Fa in Fc cannot be resolved due to an
>ambiguity between A and A.

>I also tried making A a private base class of B, so Fa would not be
>accessible through B, but it didn't make any difference.

>What I would like is for the ambiguity in C to be resolved in favor of the
>direct base A, but after reviewing the only C++ language reference material
>I have, I was unable to determine what the rule should be.

>I'd appreciate it if one of you language gurus could explain to me what the
>correct interpretation is and if there is any way to resolve/avoid  the
>ambiguity (oh, and I do not wish to use virtual bases in this case)

This is a problem, that I have complained about to the C++ standards
committee. Though classes with distinct direct and indirect copies of the
same base class are explicitly declared to be legal, they are treated very
shabbily.  There is no way, short of methods best used in obfusicated c++
contests, for unambiguously referring to the direct copy of the duplicated
base.  I suggest that you rethink the way you organize your class.
B
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      Department Fax: 1 630 840 3785
---
[ 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
]

David Sachs wrote:
 >
 > "Michael Joseph Dalpee" <mjdalpee@wizardsoftware.com> writes:
 >
 > >Hi,
 >
 > >I have run into a compilation problem trying to use repeated subobjects.  I
 > >have compiled the code below on VC++5.0 and Digital Unix 5.5, and although
 > >neither is happy with it, they give different reasons:
 >
 > >class A
 > > {
 > >public:
 > > void
 > > Fa(){}
 > >};
 >
 > >class B : A
 > > {
 > >public:
 > > void
 > > Fb(){Fa();}
 > >};
 >
 > >class C : B, A
 > > {
 > >public:
 > > void
 > > Fc(){Fa();}
 > >};
 >
 > [[CUT]]
 >
 > This is a problem, that I have complained about to the C++ standards
 > committee. Though classes with distinct direct and indirect copies of the
 > same base class are explicitly declared to be legal, they are treated very
 > shabbily.  There is no way, short of methods best used in obfusicated c++
 > contests, for unambiguously referring to the direct copy of the duplicated
 > base.  I suggest that you rethink the way you organize your class.
 > B
 > base

Hmmmm. I thought that this situation was covered.  Isn't this what the
virtual class was designed to cover, should you only want the one
instantiation, or to specifically scope the class? eg B::A::Fa()

   \\\\///// Matt Kern
   |       | mwk20@cam.ac.uk       http://xanadu.pet.cam.ac.uk/~mwk20
   | O   O |
   |   L   |   Make it possible for programmers to write in English,
   | \__   | and you will only find out they cannot write in English.
    \_____/
---
[ 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                             ]

Hi,

I have run into a compilation problem trying to use repeated subobjects.  I
have compiled the code below on VC++5.0 and Digital Unix 5.5, and although
neither is happy with it, they give different reasons:

class A
 {
public:
 void
 Fa(){}
};


class B : A
 {
public:
 void
 Fb(){Fa();}
};

class C : B, A
 {
public:
 void
 Fc(){Fa();}
};

VC gives the following error:
error C2584: 'C' : direct base 'A' is inaccessible; already a base of 'B'

While DU complains that the call to Fa in Fc cannot be resolved due to an
ambiguity between A and A.

I also tried making A a private base class of B, so Fa would not be
accessible through B, but it didn't make any difference.

What I would like is for the ambiguity in C to be resolved in favor of the
direct base A, but after reviewing the only C++ language reference material
I have, I was unable to determine what the rule should be.

I'd appreciate it if one of you language gurus could explain to me what the
correct interpretation is and if there is any way to resolve/avoid  the
ambiguity (oh, and I do not wish to use virtual bases in this case)

Thanks,

Mike
---
[ 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                             ]

Michael Joseph Dalpee writes:

> VC gives the following error:
> error C2584: 'C' : direct base 'A' is inaccessible; already a base of 'B'

It is correct.  In fact, any access to base 'A' I can think of is
invalid due to ambiguity, so that direct base 'A' is really
inaccessible.

> While DU complains that the call to Fa in Fc cannot be resolved due to an
> ambiguity between A and A.

So it is also correct.

> I also tried making A a private base class of B, so Fa would not be
> accessible through B, but it didn't make any difference.

It shouldn't.  Overload resolution must take place before access
verification, so access specifiers won't help at all.

> What I would like is for the ambiguity in C to be resolved in favor of the
> direct base A, but after reviewing the only C++ language reference material
> I have, I was unable to determine what the rule should be.

If you want that, don't make `A' a direct base class; add an extra
level of indirection:

class A_direct : public A { /* you may add some constructors */ };

class C : public B, public A_direct {
  /* use B::Fa() or A_direct::Fa() to disambiguate now */
};

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ 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                             ]

"Michael Joseph Dalpee" <mjdalpee@wizardsoftware.com> writes:

>I have run into a compilation problem trying to use repeated subobjects.  I
>have compiled the code below on VC++5.0 and Digital Unix 5.5, and although
>neither is happy with it, they give different reasons:
>
>class A
> {
>public:
> void
> Fa(){}
>};
>
>
>class B : A
> {
>public:
> void
> Fb(){Fa();}
>};
>
>class C : B, A
> {
>public:
> void
> Fc(){Fa();}
>};

All inheritence in this example is private, since you didn't explicitly
say `: public'.  Hence both calls to Fa() are ill-formed.

The second call to Fa() is also ambiguous.

>VC gives the following error:
>error C2584: 'C' : direct base 'A' is inaccessible; already a base of 'B'
>
>While DU complains that the call to Fa in Fc cannot be resolved due to an
>ambiguity between A and A.

The exact error messages given is a quality-of-implementation issue...

>I also tried making A a private base class of B, so Fa would not be
>accessible through B, but it didn't make any difference.

No, it wouldn't.  That's because ambiguity is checked before accessibility.

>What I would like is for the ambiguity in C to be resolved in favor of the
>direct base A, but after reviewing the only C++ language reference material
>I have, I was unable to determine what the rule should be.
>
>I'd appreciate it if one of you language gurus could explain to me what the
>correct interpretation is and if there is any way to resolve/avoid  the
>ambiguity (oh, and I do not wish to use virtual bases in this case)

One way to do it is to introduce a dummy class

 class WrapA : public A {
  // forward the constructors, if necessary
 };

You can then define C as

 class C : public B, public WrapA {
 public:
  void Fc() { WrapA::Fa(); }
 };

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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
]