answer this inheritance question please ..

#include <iostream>
using namespace std;
class CPolygon {
protected:
int width, height;
public:
void set_values (int a, int b)
{ width=a; height=b;}
};
class CRectangle: public CPolygon {
public:
int area ()
{ return (width * height); }
};
class CTriangle: public CPolygon {
public:
int area ()
{ return (width * height / 2); }
};
int main () {
CRectangle rect;
CTriangle trgl;
rect.set_values (4,5);
trgl.set_values (4,5);
cout << rect.area() << endl;
cout << trgl.area() << endl;
return 0;
}

guys i know that members of the derived class cannot access the private members inherited from base class .

my question is , suppose we change the code like this :-
class CPolygon {
private:
int width, height;
public:
void set_values (int a, int b)
{ width=a; height=b;}
};

here , we changed it to private , now while inheriting the set_vaues function will be inherited ..
so in inherited class we will have this function plus the new class functions ..
i clearly understand that the derived class functions will not be able to access private members , but does the
inherited "set_values" function in the inherited class will be able to access it ??
does none of the functions will be able to access the inherited private members of the base class ??

Thanks !!
 
What i think is Private members cannot be accessed through inheritance, i maybe wrong :)
you are right but i have confusion regarding the inherited function which used to access the private members in the base class , now its in derived class will it access or not ??
 
Yes.

The access specifiers are used to define restrictions on access from outside the class. All members of the same class have unrestricted access to each other.
Even if you change the access specifier for the variables from protected to private, the set_values() function has access to it's own class variables.

Hope this helps. If you have any more doubts, ask away.
 
Yes.

The access specifiers are used to define restrictions on access from outside the class. All members of the same class have unrestricted access to each other.
Even if you change the access specifier for the variables from protected to private, the set_values() function has access to it's own class variables.

Hope this helps. If you have any more doubts, ask away.

yes for the Cpolygon class , but
is it true for the derived class set_values() function to access the derived private data members present in the derived object ??
 
to put it in a simple way, trgl.set_values() will still cal the CPolygon::set_values() unless you override it. hence; in this case set_values will be able to access CPolygon::height and CPolygon::width.
 
While I'm totally out of touch with C++ , but from the point of Inheritance:

Yes, the derived class can access the METHOD set_values. It can also pass values to a and b.
Those value will be transferred to width and height.

However, if you try to access width and height from the derived class, you won't be able to do that.
For example if you make width and height static, and directly try to access them , you won't be able to as they are private.

Again, I'm out of touch with C++ , but at least this is how it will behave in ABAP.
 
^ yes, you can use friend function to solve the problem. but... using friend function will defeat the "encapsulation&abstraction" of OOPs. so, if you have to use friend function to solve a problem, may be your class design is wrong in the first place.
 
A minor point : Can we use friend function and solve the problem ??????

Why exactly do you want to use friend here when you can achieve same result by using protected on the data members.

While I don't agree with booo that friend breaks OOPS altogether, but I would say that usage of friend should be done after careful deliberation for appropriate use cases only. Don't use it arbitrarily.

Do friends violate encapsulation?

No! If they're used properly, they enhance encapsulation.

You often need to split a class in half when the two halves will have different numbers of instances or different lifetimes. In these cases, the two halves usually need direct access to each other (the two halves used to be in the same class, so you haven't increased the amount of code that needs direct access to a data structure; you've simply reshuffled the code into two classes instead of one). The safest way to implement this is to make the two halves friends of each other.
If you use friends like just described, you'll keep private things private. People who don't understand this often make naive efforts to avoid using friendship in situations like the above, and often they actually destroy encapsulation. They either use public data (grotesque!), or they make the data accessible between the halves via public get() and set() member functions. Having apublic get() and set() member function for a private datum is OK only when the private datum "makes sense" from outside the class (from a user's perspective). In many cases, theseget()/set() member functions are almost as bad as public data: they hide (only) the name of the private datum, but they don't hide the existence of the private datum.
Similarly, if you use friend functions as a syntactic variant of a class's public access functions, they don't violate encapsulation any more than a member function violates encapsulation. In other words, a class's friends don't violate the encapsulation barrier: along with the class's member functions, they are the encapsulation barrier.
(Many people think of a friend function as something outside the class. Instead, try thinking of a friend function as part of the class's public interface. A friend function in the class declaration doesn't violate encapsulation any more than a public member function violates encapsulation: both have exactly the same authority with respect to accessing the class's non-public parts.)

Do friends violate encapsulation?, C++ FAQ


One more FAQ that I think is relavent here.

I've been told to never use protected data, and instead to always use private data with protected access functions. Is that a good rule?

Nope.
Whenever someone says to you, "You should always make data private," stop right there — it's an "always" or "never" rule, and those rules are what I call one-size-fits-all rules. The real world isn't that simple.
Here's the way I say it: if I expect derived classes, I should ask this question: who will create them? If the people who will create them will be outside your team, or if there are a huge number of derived classes, then and only then is it worth creating a protected interface and using private data. If I expect the derived classes to be created by my own team and to be reasonable in number, it's just not worth the trouble: use protected data. And hold your head up, don't be ashamed: it's the right thing to do!
The benefit of protected access functions is that you won't break your derived classes as often as you would if your data was protected. Put it this way: if you believe your users will be outside your team, you should do a lot more than just provide get/set methods for your private data. You should actually create another interface. You have a public interface for one set of users, and a protected interface for another set of users. But they both need an interface that is carefully designed — designed for stability, usability, performance, etc. And at the end of the day, the real benefit of privatizing your data (including providing an interface that is coherent and, as much as possible, opaque) is to avoid breaking your derived classes when you change that data structure.
But if your own team is creating the derived classes, and there are a reasonably small number of them, it's simply not worth the effort: use protected data. Some purists (translation: people who've never stepped foot in the real world, people who've spent their entire lives in an ivory tower, people who don't understand words like "customer" or "schedule" or "deadline" or "ROI") think thateverything ought to be reusable and everything ought to have a clean, easy to use interface. Those kinds of people are dangerous: they often make your project late, since they make everything equally important. They're basically saying, "We have 100 tasks, and I have carefully prioritized them: they are all priority 1." They make the notion of priority meaningless.
You simply will not have enough time to make life easy for everyone, so the very best you can do is make life easy for a subset of the world. Prioritize. Select the people that matter most and spend time making stable interfaces for them. You may not like this, but everyone is not created equal; some people actually do matter more than others. We have a word for those important people. We call them "customers."
http://www.parashift.com/c++-faq/protected-data-not-evil.html
 
Back
Top