I have two classes, say A and B, both having a data member 'int n';
private in A, public in B.

When I derive class C from both public A and public B, B::n should be
visible to C while A::n should not be.

But if I compile with g++-4.0.3 the following snippet:

class A {
int i;
public:
A () {}
};

class B {
public:
int i;
B () {}
};

class C : public A, public B {
public:
C () { i = 3; }
};

int main () {
C c;
return 0;
}

I get the following error:

test.cpp: In constructor 'C::C()':
test:15: error: reference to 'i' is ambiguous
test:9: error: candidates are: int B::i
test:2: error: int A::i

Nothing dramatic, of course I can change the names or use access
specifiers. I just would like to know if I am misinterpreting chapter 6
of Stroustrup 2nd edition or if this is a compiler problem.

Thanks for the attention,

Daniele

dl wrote:

I have two classes, say A and B, both having a data member 'int n';

'int i;'

private in A, public in B.
>
When I derive class C from both public A and public B, B::n should be
visible to C while A::n should not be.

They are both visible. A::i, however, is *inaccessible*. The rules
of accessibility and visibility of names are orthogonal. First, the
rules of visibility are applied, then the access is *verified*. In
your case two variables that have the same name and the same type
conflict with each other. You need to tell the compiler which one
you mean to use by qualifying the name: A::i or B::i.

>
But if I compile with g++-4.0.3 the following snippet:
>
class A {
int i;
public:
A () {}
};
>
class B {
public:
int i;
B () {}
};
>
class C : public A, public B {
public:
C () { i = 3; }
};
>
int main () {
C c;
return 0;
}
>
I get the following error:
>
test.cpp: In constructor 'C::C()':
test:15: error: reference to 'i' is ambiguous
test:9: error: candidates are: int B::i
test:2: error: int A::i
>
Nothing dramatic, of course I can change the names or use access
specifiers.

Wrong terminology. The syntax 'B::' (or 'A::') is called "nested name
specifier". Access specifier is the "private" or "public".

I just would like to know if I am misinterpreting chapter
6 of Stroustrup 2nd edition or if this is a compiler problem.

Most likely.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Victor Bazarov ha scritto:

dl wrote:

>
'int i;'
>

>
They are both visible. A::i, however, is *inaccessible*. The rules
of accessibility and visibility of names are orthogonal. First, the
rules of visibility are applied, then the access is *verified*. In
your case two variables that have the same name and the same type
conflict with each other. You need to tell the compiler which one
you mean to use by qualifying the name: A::i or B::i.
>

>
Wrong terminology. The syntax 'B::' (or 'A::') is called "nested name
specifier". Access specifier is the "private" or "public".
>

>
Most likely.
>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Thank you.

I get the following error:

>
test.cpp: In constructor 'C::C()':
test:15: error: reference to 'i' is ambiguous
test:9: error: candidates are: int B::i
test:2: error: int A::i
>
Thanks for the attention,
>
Daniele

This is not a compiler error, rather it is a constant plauge on
multiple inheretance (spelling?)... Because the object C is a child of
both A and B, it inherents variable i from both despite the fact that
it is not made public (for more information, look up the keywords
'private' and 'protected'). I would not recommend using multiple
inheritance unless you are more comforatable with the concept (it also
adds a bit of overhead to your applications). However, if you would
like tho continue, I beleive the problem here can be resolved by use of
the 'virtual' keyword. When you declare a class 'virtual' you are
stating that when inherited it objects should inherit all values unless
they already exist for some reason (more or less... mostly less). What
you should probably do is create another virtual class (lets say E)
that contains i, have A and B inherit from E and then have C inherit
from A and B. Hope that helps and isn't to vauge or confusing...
-Leif902
http://www.greenmangames.vze.com

(or if you don't want to do all that, you can just reference the
class... like 'c.A::i', this however is not a very good solution as it
forces class information to be placed in application code which is a
big no...)

Leif902 ha scritto:

>
This is not a compiler error, rather it is a constant plauge on
multiple inheretance (spelling?)... Because the object C is a child of
both A and B, it inherents variable i from both despite the fact that
it is not made public (for more information, look up the keywords
'private' and 'protected'). I would not recommend using multiple
inheritance unless you are more comforatable with the concept (it also
adds a bit of overhead to your applications). However, if you would
like tho continue, I beleive the problem here can be resolved by use of
the 'virtual' keyword. When you declare a class 'virtual' you are
stating that when inherited it objects should inherit all values unless
they already exist for some reason (more or less... mostly less). What
you should probably do is create another virtual class (lets say E)
that contains i, have A and B inherit from E and then have C inherit
from A and B. Hope that helps and isn't to vauge or confusing...
-Leif902
http://www.greenmangames.vze.com
>
(or if you don't want to do all that, you can just reference the
class... like 'c.A::i', this however is not a very good solution as it
forces class information to be placed in application code which is a
big no...)

Thank you, too.

I must say that IMHO this is not a very good feature of C++. Objects
should be free of having *private* variables of any name and any type,
without clash with any usage which can be done of the object, including
multiple inheritance. If I need a variable for local purposes in my
object A, once I declare it private, why should I also worry about the
fact that the same name and type could be present in a completely
different object B, maybe writted by somebody else, and that both A and
B could be inherited by C, maybe written by a third person?
Anyway if it is like that, I must comply.

Regards,

dl

dl wrote:

Leif902 ha scritto:
>

>
Thank you, too.
>
I must say that IMHO this is not a very good feature of C++. Objects
should be free of having *private* variables of any name and any type,
without clash with any usage which can be done of the object, including
multiple inheritance. If I need a variable for local purposes in my
object A, once I declare it private, why should I also worry about the
fact that the same name and type could be present in a completely
different object B, maybe writted by somebody else, and that both A and
B could be inherited by C, maybe written by a third person?
Anyway if it is like that, I must comply.

You can reduce it to a single name using something like this:

class A {
public:
A( int first, int second, int third ) : members( first, second, third
) {}
private:
struct members_t {
members_t( int first, int second, int third ) : a( first ), b( second
), c( third ) {}
int a, b, c;
} members;
};

Depending on what you're doing you'll have to forward some
constructors.

Probably not worth the extra effort though unless you're implementing a
library and name clashes are a problem. There's also pimpl.


K

Kirit Sælensminde ha scritto:

dl wrote:
>

>
You can reduce it to a single name using something like this:
>
class A {
public:
A( int first, int second, int third ) : members( first, second, third
) {}
private:
struct members_t {
members_t( int first, int second, int third ) : a( first ), b( second
), c( third ) {}
int a, b, c;
} members;
};
>
Depending on what you're doing you'll have to forward some
constructors.
>
Probably not worth the extra effort though unless you're implementing a
library and name clashes are a problem. There's also pimpl.
>
>
K

Thank you Kirit.

I didn't know pimpl (looks like a bad word). Do you mean the thing
described eg in
http://www.gamedev.net/reference/art...rticle1794.asp ? Thanks for
pointing it out.

Anyway all possible solutions, including pimpl, look clumsy to me; the
point is that I see no reason to have something visible and
inaccessible, to use the words of Victor. If A::i is inaccessible, then
in fact there is no ambiguity.

Regards,

dl

Leif902 ha scritto:

I beleive the problem here can be resolved by use of
the 'virtual' keyword. When you declare a class 'virtual'

If I declare the class 'virtual', g++ complains as follows:

error: 'virtual' can only be specified for functions

you are
stating that when inherited it objects should inherit all values unless
they already exist for some reason (more or less... mostly less). What
you should probably do is create another virtual class (lets say E)
that contains i, have A and B inherit from E and then have C inherit
from A and B. Hope that helps and isn't to vauge or confusing...

Regards,

dl

Leif902 wrote:

>
This is not a compiler error, rather it is a constant plauge on
multiple inheretance (spelling?)... Because the object C is a child of
both A and B,

C is not an object. It's a type. If you slur that distinction you'll be
constantly lost.

it inherents variable i from both despite the fact that

it is not made public (for more information, look up the keywords
'private' and 'protected'). I would not recommend using multiple
inheritance unless you are more comforatable with the concept (it also
adds a bit of overhead to your applications). However, if you would
like tho continue, I beleive the problem here can be resolved by use of
the 'virtual' keyword.

No, that won't help.

When you declare a class 'virtual' you are

stating that when inherited it objects should inherit all values unless
they already exist for some reason (more or less... mostly less).

Far less. A base class can be labeled virtual, and if there's more than
one virtual base of that type, they'll be merged. That applies to base
classes, not to random data items that happen to have the same name.
Here, the conflicting names come from two different base classes, so
virtual bases won't help.

What

you should probably do is create another virtual class (lets say E)
that contains i, have A and B inherit from E and then have C inherit
from A and B.

This assumes that it's okay for A and B to share the same copy of i.
There's nothing here to indicate that that's the case.

--

-- Pete
Roundhouse Consulting, Ltd. -- www.versatilecoding.com
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

dl wrote:

Leif902 ha scritto:
>

>
If I declare the class 'virtual', g++ complains as follows:
>
error: 'virtual' can only be specified for functions
>

As I said elsewhere, virtual is not the answer. It can be applied to
base classes, which is what the other poster was talking about, but that
doesn't solve this problem.

As you said in the beginning, you need to either change one of the names
or use the qualified name B::i whenever you refer to i.

--

-- Pete
Roundhouse Consulting, Ltd. -- www.versatilecoding.com
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

i mean declare it virtual upon inhereting it...

ex. class C would inherit normally from public A or something... so put
virtual public A instead in the inheritance statement... that will fix
it... like this:

(Taken From C++ For Dummies)

class Base
{
public:
base() {}
int i;
};

class A : virtual public base
{
// constructor and A specific members...
};

class B : virtual public base
{
// stuff
};

class C : public A, public B
{
// stuff
};

like that should do the trick and be less messey upon compile time than
the other answers presented.

Leif902 wrote:

i mean declare it virtual upon inhereting it...
>
ex. class C would inherit normally from public A or something... so put
virtual public A instead in the inheritance statement... that will fix
it... like this:
>

Virtual inheritance is appropriate when a class design involves elements
that must be shared between derived types. There's nothing in the
problem statement to indicate that that's the case here. In fact, since
the two base classes have different access specifiers, it suggests that
that's not the case.

Don't automatically react to name conflicts by stuffing in virtual
inheritance. That does far more than eliminate some conflicts. It's a
fundamental design change, and should be based on a decision that that's
the appropriate design. It's not a hack for quick fixes to
half-understood problems.

--

-- Pete
Roundhouse Consulting, Ltd. -- www.versatilecoding.com
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

oh pardon me, but it seemed to work well when I tried it :)
-Leif902

Leif902 wrote:

oh pardon me, but it seemed to work well when I tried it :)
-Leif902
>

That depends on what you mean by "work well." You probably got rid of
the error message, but you changed the meaning of the code. In
particular, if you did what you described earlier, modifications to i
made by member functions of A would also change the value of i seen by
member functions of B, which wasn't the case in the original code. Now,
if you know that the original version didn't reflect the actual
requirements and that your version does, that's fine, but I suspect
that's not the case.

--

-- Pete
Roundhouse Consulting, Ltd. -- www.versatilecoding.com
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

dl wrote:

Kirit Sælensminde ha scritto:
>

>
Thank you Kirit.
>
I didn't know pimpl (looks like a bad word). Do you mean the thing
described eg in
http://www.gamedev.net/reference/art...rticle1794.asp ? Thanks for
pointing it out.

Yes, it's basically the same as the embedded struct that I showed, but
you store a pointer to it and define the struct privately in your
implementation file.

I think the name pimpl was chosen on purpoise to look bad, or at least
cute :-)

>
Anyway all possible solutions, including pimpl, look clumsy to me; the
point is that I see no reason to have something visible and
inaccessible, to use the words of Victor. If A::i is inaccessible, then
in fact there is no ambiguity.

Don't forget that using directives in derived classes can change the
access specifier. You may also be able to use one to bring the member
you want out and hide the other. Play around with something like:

using B::i;

For whichever class's i you want to use. That may also sort it out for
you.

Which is the correct/best solution for you does depend on context to a
certain extent. If I was using the classes in an application then I'd
probably just use whichever was expedient. If the classes where in a
library then I'd probably go for an embedded struct or pimpl depending
on whether or not sub-classes may require some sort of access as this
will hide the implementation better for programmers using the library.


K