Richard Corden wrote:

> kanze@gabi-soft.de (James Kanze) writes:
>
> > > class V { public: int f();  int x; };
> > > class W { public: int g();  int y; };
> >
> > > class B : public virtual V, public W
> > > {
> > > public:
> > >     int f();  int x;
> > >     int g();  int y;
> > > };
> >
> > > class C : public virtual V, public W { };
> >
> > > class D : public B, public C
> > > {
> > >   void D::glorp()
> > >   {
> > >     x++;     // OK: B::x hides V::x
> >
> > This should be ambiguous, since B::x doesn't hide C::W::x.
> Maybe you've misread the example above as W does have an x.
>
> > And I guess that that is the rationale -- it works better in practice
> > than any proposed alternative.
>
> Consider the following:
>
> struct A
> {
>   int m;
> };
>
> struct B : virtual A
> {};
>
> sturct C : virtual A
> {};
>
> struct D : B, C
> {
>   void foo ()
>   {
>     m;
>   }
> };
>
> The above is not ambigous as there is only one m, however if you
> now add a member m to B, silently B::m is the name which is found.

Isn't is B::m "more derived" than A::m (it's closer in the family tree)?
In that case, B::m should be found and there is no ambiguity.

> For me this is dangerous...

Could not agree more.

Shao Wu.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hi,

Can someone explain the rationale behind 10.2/6, i.e. why it's not
ambiguous?

"When virtual base classes are used, a hidden declaration can be
reached along a path through the sub-object lattice that does not
pass through the hiding declaration. This is not an ambiguity."

Also, does 'a hidden declaration can be reached' imply this 'hidden
declaration' is the one which is found?, i.e. V::x is the x found
in the example?

class V { public: int f();  int x; };
class W { public: int g();  int y; };

class B : public virtual V, public W
{
public:
    int f();  int x;
    int g();  int y;
};

class C : public virtual V, public W { };

class D : public B, public C
{
  void D::glorp()
  {
    x++;     // OK: B::x hides V::x
  }
};


Thanks,

Richard

--
Richard Corden
To reply remove 's' from address

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Richard Corden <richards_corden@hotmail.com> wrote in message
news:<83y9glan5w.fsf@leinster.programmingresearch.ie>...

> Can someone explain the rationale behind 10.2/6, i.e. why it's not
> ambiguous?

Probably because the rule works well in practice.

> "When virtual base classes are used, a hidden declaration can be
> reached along a path through the sub-object lattice that does not
> pass through the hiding declaration. This is not an ambiguity."

> Also, does 'a hidden declaration can be reached' imply this 'hidden
> declaration' is the one which is found?, i.e. V::x is the x found in
> the example?

> class V { public: int f();  int x; };
> class W { public: int g();  int y; };

> class B : public virtual V, public W
> {
> public:
>     int f();  int x;
>     int g();  int y;
> };

> class C : public virtual V, public W { };

> class D : public B, public C
> {
>   void D::glorp()
>   {
>     x++;     // OK: B::x hides V::x

This should be ambiguous, since B::x doesn't hide C::W::x.

>   }
> };

When you read the rules, they may sound complex and difficult to
understand.  But I've worked on several projects where extremely
complex inheritance hierarchies were used, and the result of the rules
always turned out to be what we wanted, and what the developers (not
all gurus, by any means) intuitively expected.

And I guess that that is the rationale -- it works better in practice
than any proposed alternative.

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orient   e objet
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany, T   l.: +49 (0)69 19 86 27

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

kanze@gabi-soft.de (James Kanze) writes:

> > class V { public: int f();  int x; };
> > class W { public: int g();  int y; };
>
> > class B : public virtual V, public W
> > {
> > public:
> >     int f();  int x;
> >     int g();  int y;
> > };
>
> > class C : public virtual V, public W { };
>
> > class D : public B, public C
> > {
> >   void D::glorp()
> >   {
> >     x++;     // OK: B::x hides V::x
>
> This should be ambiguous, since B::x doesn't hide C::W::x.
Maybe you've misread the example above as W does have an x.


> And I guess that that is the rationale -- it works better in practice
> than any proposed alternative.

Consider the following:

struct A
{
  int m;
};

struct B : virtual A
{};

sturct C : virtual A
{};

struct D : B, C
{
  void foo ()
  {
    m;
  }
};

The above is not ambigous as there is only one m, however if you
now add a member m to B, silently B::m is the name which is found.

For me this is dangerous...

Richard

--
Richard Corden
To reply remove 's' from address

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]