private within this context, the mind of man is surely not this twisted ?

[Greg]

class a
{
public:
int x;
private:
int y;
}

class b : public a
{
public:
void b::somemethod()
}

void b::somemethod()
{
y = 20; // <- compiler error, what? no, the mind of man is surely
not this twisted
}

I was expecting b to have everything a has and "somemethod"
WTF ?

[Victor Bazarov]

Greg wrote:

class a
{
public:
int x;
private:
int y;
}

;

>
class b : public a
{
public:
void b::somemethod()

;

}

;

>
void b::somemethod()
{
y = 20; // <- compiler error, what? no, the mind of man is surely
not this twisted

Huh? 'y' is private. It cannot be accessed *except* from a member
of 'a' or from its *friend*. 'b' is not a member and not a friend.
That's why 'y' is not accessible.

}

I was expecting b to have everything a has and "somemethod"
WTF ?

Read your favorite C++ book again, especially the part where
'private' is explained.

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

[robertwessel2]

Greg wrote:

class a
{
public:
int x;
private:
int y;
}

class b : public a
{
public:
void b::somemethod()
}

void b::somemethod()
{
y = 20; // <- compiler error, what? no, the mind of man is surely
not this twisted
}

I was expecting b to have everything a has and "somemethod"
WTF ?

A derived class cannot access private members in the base class. The
derived class *can* access public and protected members in the base.
The only way for a derived class to access private members in the base
is for the base class to declare the derived class (or at least the
member function in question) a friend.

[Greg]

Bleargh, my C++ hateometer is at 8.6, that design is cac. So how do I
derive a class that can access the private members ? Or how can I make
the same overall design and avoid this dilema ?

[Greg]

Victor Bazarov wrote:

Huh? 'y' is private. It cannot be accessed *except* from a member
of 'a' or from its *friend*. 'b' is not a member and not a friend.
That's why 'y' is not accessible.

Read your favorite C++ book again, especially the part where
'private' is explained.

Yes, I misunderstand "private", I thought it meant private to the users
(scope) of the object but it obviously means more than that. Can you
declare b as a friend of a like this ?
class b : friend a
{
// unbleargh, maybe ?
};

[Phlip]

Greg wrote:

Bleargh, my C++ hateometer is at 8.6, that design is cac.

You truly don't know C++ very well if you still score < 9.0.

So how do I
derive a class that can access the private members ?

Don't. That's what encapsulation means: You can change private members of
one class without wondering to yourself what other classes you just screwed
up - even if they are derived classes.

If you simply must do what you are doing, use 'protected'.

However, in general, one class should use the "tell, don't ask" when using
another class - eeeven a base class. The client class should not ask the
servant class what its 'y' value is. It should tell the servant class what
high-level operation it should do. That way, the servant class can use 'y'
the way it likes, and 'y' has a known and narrow scope. Eeeeeeeven if the
servant class is also a base class.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Kai-Uwe Bux]

Greg wrote:

Bleargh, my C++ hateometer is at 8.6, that design is cac. So how do I
derive a class that can access the private members ? Or how can I make
the same overall design and avoid this dilema ?

Make those members of the base class that should be visible to derived
classes protected instead of private. They will still be inaccessible from
classes outside the hierarchy.
Best

Kai-Uwe Bux

[David W]

"Greg" <im*****@hotmail.co.ukwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

>
Victor Bazarov wrote:

Huh? 'y' is private. It cannot be accessed *except* from a member
of 'a' or from its *friend*. 'b' is not a member and not a friend.
That's why 'y' is not accessible.

Read your favorite C++ book again, especially the part where
'private' is explained.

Yes, I misunderstand "private", I thought it meant private to the users
(scope) of the object but it obviously means more than that. Can you
declare b as a friend of a like this ?
class b : friend a
{

No. There's not much point in making something private if there's an easy way to get around it. Only
a can choose who its friends are. Private means _private_.

// unbleargh, maybe ?
};

DW

[Phlip]

Kai-Uwe Bux wrote:.

Make those members of the base class that should be visible to derived
classes protected instead of private. They will still be inaccessible from
classes outside the hierarchy.

Can a derived class use this?

public:
using I_formerly_was_protected;

If so, privacy is even less of an illusion of encapsulation...

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Salt_Peter]

Greg wrote:

Bleargh, my C++ hateometer is at 8.6, that design is cac. So how do I
derive a class that can access the private members ? Or how can I make
the same overall design and avoid this dilema ?

If it's private, then its up to the base class to give you access to
it. Why is it that you beleive that you can't access it?

class a
{
int y;
public:
void setY(int n) { y = n; }
int getY() const { return y; }
}; <- semicolon! its a class declaration

class b : public a
{
public:
void b::somemethod() const;
};

void b::somemethod()
{
setY(20);
}

Now consider a situation where you need to only allow y to be between 0
and 20, as an example. Why should the programmer be forced to have
those classes NOT responsible for the variable check that?
The point is that if y is protected, then class b must also impose the
0 <= y <= 20 verification. Thats would be a dumb strategy. The fact
that y above is private is helping the creator of the class determine
the rules of the design. Can you see that even an instance of class b
can now set/get y?

int main()
{
b bill;
bill.setY(11);
}

[Kai-Uwe Bux]

Phlip wrote:

Kai-Uwe Bux wrote:.

>Make those members of the base class that should be visible to derived
classes protected instead of private. They will still be inaccessible
from classes outside the hierarchy.

Can a derived class use this?

public:
using I_formerly_was_protected;

Yes.

If so, privacy is even less of an illusion of encapsulation...

So?
Best

Kai-Uwe Bux