By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,314 Members | 1,745 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,314 IT Pros & Developers. It's quick & easy.

C++ quiz question: private inheritance

P: n/a
Hello everybody, today I had another quiz question
"if class X is privately derived from base class Y what is the scope of
the public, protected, private members of Y will be in class X"

By scope they meant public/protected/private access modifiers :)
Obviously all members of the base privately inherited class will be
private, and that was my answer. However, the teacher checked my
answers when I handed in, and the problem was that I had to specify
that private members of base class are not inherited (that the way he
called that they were inaccessible from inside of the derived class),
however, it doesn't make my answer incorrect - all of them are still
private. The question from the beginning didn't mean anything that I
had to specify if the private members were accessible or not, I only
had to specify their "scope".

Was my answer correct or not?
thanks

Oct 20 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
__PPS__ wrote:
Hello everybody, today I had another quiz question
"if class X is privately derived from base class Y what is the scope of
the public, protected, private members of Y will be in class X"

By scope they meant public/protected/private access modifiers :)
You should definitely suggest the change in terminology to them.
Obviously all members of the base privately inherited class will be
private, and that was my answer.
That's all? Seems too simple an answer...
However, the teacher checked my
answers when I handed in, and the problem was that I had to specify
that private members of base class are not inherited (that the way he
called that they were inaccessible from inside of the derived class),
however, it doesn't make my answer incorrect - all of them are still
private. The question from the beginning didn't mean anything that I
had to specify if the private members were accessible or not, I only
had to specify their "scope".

Was my answer correct or not?


Correct? I don't know, I am not the one who asked. Incomplete, for
sure. This is a bit more complete:

(assuming X is not made a friend of Y)

Private in Y -> inaccessible in X (inheritance doesn't matter)
Protected in Y -> accessible in X (through inheritance)
Public in Y -> accessible in X (like anywhere)

Any member of X::Y is not available to anybody outside of X unless
it's a friend of X. For a friend of X only public and protected
members of X::Y are visible through X (just like inside X itself).

If you derive another class from X (and it's not a friend), then no
member of X::Y is visible to it (despite the fact that Y has it own
public members). That's a bit of a pitfall in the language, but if
you are aware of it, you're not going to fall in.

class Y {
protected:
void foo();
};

class X : Y {
protected:
void bar() { Y::foo(); } // fine
};

class W : X {
void baz() {
X::bar(); // fine
Y y; // inaccessible
this->X::Y::foo(); // error - inaccessible
}
};

V
Oct 20 '05 #2

P: n/a
__PPS__ wrote:
Obviously all members of the base privately inherited class will be
private, and that was my answer. However, the teacher checked my
answers when I handed in, and the problem was that I had to specify
that private members of base class are not inherited (that the way he
called that they were inaccessible from inside of the derived class),
however, it doesn't make my answer incorrect - all of them are still
private. The question from the beginning didn't mean anything that I
had to specify if the private members were accessible or not, I only
had to specify their "scope".

Was my answer correct or not?


I'd say "no". A member is private in a class if that class and its friends
(and only those) can access it. But a member that was private in the base
class cannot be accessed at all in the derived class, so it's not private
in that derived class.

Oct 21 '05 #3

P: n/a
> > By scope they meant public/protected/private access modifiers :)

You should definitely suggest the change in terminology to them.
Done that :) I put a line about the real class scope of the members. If
I didn't ask these questions about my quizes here, there was a chance
that I would start to use their terminology; most likely everybody in
the class will use this terminology
Obviously all members of the base privately inherited class will be
private, and that was my answer.
That's all? Seems too simple an answer...


This is a basic c++ class, no details (especialy friends etc) are
necessary; we had almost no space to write this answer - there was
enough space for about 10-15 words of normal handwriten text (on the
answer sheets provided by the tutor)
> However, the teacher checked my
answers when I handed in, and the problem was that I had to specify
that private members of base class are not inherited (that the way he
called that they were inaccessible from inside of the derived class),
however, it doesn't make my answer incorrect - all of them are still
private. The question from the beginning didn't mean anything that I
had to specify if the private members were accessible or not, I only
had to specify their "scope".

Was my answer correct or not?
Correct? I don't know, I am not the one who asked. Incomplete, for
sure. This is a bit more complete:


I agree that it's not complete when it comes to details, but does the
original question ask for it? or it just asks for the "scope"?
When I read the question I even had no idea that it was related to
accessibility of that members, although I know that they become
inaccessible
(assuming X is not made a friend of Y)

Private in Y -> inaccessible in X (inheritance doesn't matter)
Protected in Y -> accessible in X (through inheritance)
Public in Y -> accessible in X (like anywhere)

Any member of X::Y is not available to anybody outside of X unless
it's a friend of X. For a friend of X only public and protected
members of X::Y are visible through X (just like inside X itself).

If you derive another class from X (and it's not a friend), then no
member of X::Y is visible to it (despite the fact that Y has it own
public members). That's a bit of a pitfall in the language, but if
you are aware of it, you're not going to fall in.
I assume it will happen only with private inheritance, right?

class Y {
protected:
void foo();
};

class X : Y {
protected:
void bar() { Y::foo(); } // fine
};

class W : X {
void baz() {
X::bar(); // fine
Y y; // inaccessible
This really looks strange to me - we cannot create temporary object of
class Y that has public constructor :) If I didn't check it with a
compiler I would think that you were wrong about that!
this->X::Y::foo(); // error - inaccessible
Here syntax looks a bit strange to me, I always write it like
X::Y::foo(); without this->. Is it ok to do so?
}
};

V


Oct 21 '05 #4

P: n/a
> I'd say "no". A member is private in a class if that class and its friends
(and only those) can access it. But a member that was private in the base
class cannot be accessed at all in the derived class, so it's not private
in that derived class.

You are right, it's not private according to your reasoning, but how is
it called then if it's not private/protected/public?
Privately inherited private members, basicly, become private for class
scope members. How do we call such private private members then?
Our teacher in class called them "not inherited" which is a little bit
misleading - it's likely to make students believe that such members are
excluded from objects of the class. This term seems to be ok for
methods, but not for data.

Oct 21 '05 #5

P: n/a
On 20 Oct 2005 18:36:21 -0700, "__PPS__" <i-*********@yandex.ru>
wrote:
I'd say "no". A member is private in a class if that class and its friends
(and only those) can access it. But a member that was private in the base
class cannot be accessed at all in the derived class, so it's not private
in that derived class.

You are right, it's not private according to your reasoning, but how is
it called then if it's not private/protected/public?
Privately inherited private members, basicly, become private for class
scope members. How do we call such private private members then?
Our teacher in class called them "not inherited" which is a little bit
misleading - it's likely to make students believe that such members are
excluded from objects of the class. This term seems to be ok for
methods, but not for data.


These "not inherited" functions get called by other functions in the
parent class. This is actually no different from public inheritance;
the parent's private functions are always inaccessible to the child
class (ignoring the case of friend class/functions), and so they only
are executed when instances of the parent class call them.

In the following example, a child class that uses private inheritance
can indirectly call one of its parent's private functions:

// Parent class
class Vehicle {
private:
int mySpeed;

void setSpeed(int speed) {
mySpeed = speed;
}

public:
void move(int speed) {
setSpeed(speed);
std::cout << "moving at " << speed << " mph"
}
};

// Child class that privately inherits Vehicle
class Car : private Vehicle {
public:
void drive() {
move(25); // <-- private function setSpeed gets called
}
}
Oct 21 '05 #6

P: n/a
__PPS__ wrote:
[..]
class W : X {
void baz() {
X::bar(); // fine
Y y; // inaccessible
This really looks strange to me - we cannot create temporary object of
class Y that has public constructor :) If I didn't check it with a
compiler I would think that you were wrong about that!


It came up a couple of times over the past month. The 'Y' member
is found first, and it's inaccessible. You need to make it

::Y y;

to instantiate the _automatic_ (not temporary) 'y'.
this->X::Y::foo(); // error - inaccessible
Here syntax looks a bit strange to me, I always write it like
X::Y::foo(); without this->. Is it ok to do so?


"this->" is superfluous, but I wanted to emphasize what we're trying
to accomplish there.
}
};

V


V
Oct 21 '05 #7

P: n/a
if there were no way to "indirectly" call private functions then they
would not be any useful. Just think about it ... they are always
inderectly called by some means

Oct 21 '05 #8

P: n/a
__PPS__ wrote:
I'd say "no". A member is private in a class if that class and its
friends (and only those) can access it. But a member that was private in
the base class cannot be accessed at all in the derived class, so it's
not private in that derived class.

You are right, it's not private according to your reasoning,


Well, the C++ standard says the same. Its definition of a private member is:
"it's name can be used only by members and friends of the class in which it
is declared."
but how is it called then if it's not private/protected/public?
The C++ standard calls them "inaccessible".
Privately inherited private members, basicly, become private for class
scope members. How do we call such private private members then?
Our teacher in class called them "not inherited" which is a little bit
misleading - it's likely to make students believe that such members are
excluded from objects of the class.
Inheritance is not about what data an object contains, but about what can be
accessed though its interface.

A more complete quote than the above from the C++ standard:

<Quote>
A member of a class can be

-- private; that is, its name can be used only by members and friends of the
class in which it is declared.

-- protected; that is, its name can be used only by members and friends of
the class in which it is declared, and by members and friends of classes
derived from this class.

-- public; that is, its name can be used anywhere without access
restrictions.
</Quote>

So, as you already noted, if something was private in a base class (it
doesn't matter how you derived from it), it's neither private, nor
protected, nor public in the derived class.
Since a member must have one of those three accessibilities, one could say
that it's not a member of that class, or that the class didn't inherit the
member from the base class.
This term seems to be ok for methods, but not for data.


I think it's ok if explained in more detail. On its own, it could be
misunderstood.

Oct 21 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.