Error about inaccessable class

[Marcel Müller]

In the code below gcc says

test.cpp: In constructor `SingleInfoDialog::SingleInfoDialog(const
PlayableSetBase&)':
test.cpp:2: error: `class PlayableSetBase' is inaccessible
test.cpp:24: error: within this context

Obviosly gcc does not manage to pass the parameter of type const
PlayableSetBase& to the constructor of InfoDialog because there is a
private base class with the same name. Is this really not allowed?


Marcel


-----
class PlayableSetBase
{
};

class OwnedPlayableSet
: public PlayableSetBase
{public:
OwnedPlayableSet(const PlayableSetBase& r);
};


class InfoDialog
// a member is not sufficient because of the destruction sequence
: private OwnedPlayableSet
{protected:
InfoDialog(const PlayableSetBase& key)
: OwnedPlayableSet(key)
{}
};

class SingleInfoDialog
: public InfoDialog
{public:
SingleInfoDialog(const PlayableSetBase& key)
: InfoDialog(key) // <-- !!!
{}
};

 

[Andrey Tarasevich]

In the code below gcc says

test.cpp: In constructor `SingleInfoDialog::SingleInfoDialog(const
PlayableSetBase&)':
test.cpp:2: error: `class PlayableSetBase' is inaccessible
test.cpp:24: error: within this context

Obviosly gcc does not manage to pass the parameter of type const
PlayableSetBase& to the constructor of InfoDialog because there is a
private base class with the same name. Is this really not allowed?

There's not just a private base class with that name, but also the name
of that base class is implicitly introduced into the derived class'
scope (it is called "base class name injection"). Class
'PlayableSetBase' is a base class of class 'OwnedPlayableSet', which
means that 'PlayableSetBase' is injected into the 'OwnedPlayableSet'
scope, as if an invisible typedef declaration was there

class OwnedPlayableSet
: public PlayableSetBase
{ public:
...
typedef :layableSetBase PlayableSetBase;
...
};

Now, whenever you use the unqualified 'PlayableSetBase' in any derived
class, it actually refers not to the file-scope name, but to that
class-scope name implicitly declared in 'OwnedPlayableSet'.

In your example, 'InfoDialog' inherits from 'OwnedPlayableSet'
privately, meaning that now 'PlayableSetBase' is private in
'InfoDialog'. And finally, you are trying to access the private
'PlayableSetBase' from 'SingleInfoDialog', which causes the error.

To fix the error, tell the compiler that you want to refer to the global
'PlayableSetBase' name, not the inherited private 'PlayableSetBase' name.

class SingleInfoDialog
: public InfoDialog
{public:
SingleInfoDialog(const :layableSetBase& key)
: InfoDialog(key)
{}
};

 

[Marcel Müller]

Hi!

There's not just a private base class with that name, but also the name
of that base class is implicitly introduced into the derived class'
scope (it is called "base class name injection"). Class
'PlayableSetBase' is a base class of class 'OwnedPlayableSet', which
means that 'PlayableSetBase' is injected into the 'OwnedPlayableSet'
scope, as if an invisible typedef declaration was there

[...]

Thanks! This was the decisive hint.

I was a bit confused because the error came at the line with the copy
constructor invocation rather that the functions argument list.

To fix the error, tell the compiler that you want to refer to the global
'PlayableSetBase' name, not the inherited private 'PlayableSetBase' name.

class SingleInfoDialog
: public InfoDialog
{public:
SingleInfoDialog(const :layableSetBase& key)
: InfoDialog(key)
{}
};

That works as expected.

I only wonder a bit why

SingleInfoDialog::SingleInfoDialog(const PlayableSetBase& key) {}

does not give a similar error (assuming a suitable default constructor
of InfoDialog). Types of member function arguments are normally resolved
from within the class scope too.


Marcel

 

[Andrey Tarasevich]

That works as expected.

I only wonder a bit why

SingleInfoDialog::SingleInfoDialog(const PlayableSetBase& key) {}

does not give a similar error (assuming a suitable default constructor
of InfoDialog). Types of member function arguments are normally resolved
from within the class scope too.
...

It doesn't? That's surprising. Actually, in the original version of the
code I assumed that this is specifically the parameter declaration that
triggers the error. Meaning that the updated version should give exactly
the same error in exactly the same location for exactly the same reason.
(Actually, that's what happens in case of Comeau Online compiler - same
error). If the error is not reported by GCC in the updated version of
the code, I'd guess that this is a problem with GCC.