Click here to Skip to main content
15,868,141 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
Dear Seniors,
Can you please give some hints on how exactly i am able to inherit the functions of other class with out specifying either public or private. If i am able to then when only should I use public or private
Below is the sample code snippet for your reference.

C#
#include <iostream>
#include <string>

class A
{
    private:
        std::string name;
    public:
        void getdata( )
        {
            std::cout << "Name: ";
            std::cin  >> name;
        }
        void showdata( )
        {
            std::cout << "Your name: " << name << std::endl;
        }
};

class B
{
    private:
        std::string surname;
        A a;
    public:
        void getdata( )
        {
            a.getdata( );
            std::cout << "Surname: ";
            std::cin  >> surname;
        }
        void showdata( )
        {
            a.showdata( );
            std::cout << "Your surname: " << surname << std::endl;
        }
};

int main( )
{
    B e;
    e.getdata( );
    e.showdata( );
    return 0;
}



Regards,
Kiran
Posted

1 solution

There is no inheritance here at all.
You're simply creating an object of class A as a member variable of class B.
This is the same as how you created a std::string object inside the class or an object of class B in the main function.
So, for example, you will not be able to perform any polymorphism.
A* ptr = new B; will throw an error because this needs inheritance.
 
Share this answer
 
Comments
Emilio Garavaglia 24-Jul-11 12:39pm    
In strict C++ terminology you're right.
In more generic terms, the OP may be right too.
In generic programming, two classes with a same interface one of which is implemented by means of the other can be said it "inherits" the other functionality. That's plain English, after all.
Sergey Alexandrovich Kryukov 24-Jul-11 14:59pm    
Emilio.

First, I'll vote 5 for _Superman_.

This is not "strict C++" terminology, this is general OOP terminology; I don't want to argue how strict; I just want to say what you say is not excuse for OP. OP could possible be right is some sense if he put some note on unusual use of terminology. Why talking this kind of "plain English" if we can talk in the way to understand each other really well?

--SA
Emilio Garavaglia 25-Jul-11 13:00pm    
The point is that C++ is not a "strict OOP language". Inheritance makes sense if combined with polymorphism (otherwise is half-a-machine), but C++ has both runtime polymorphism (based on inheritance, that fits Santosh answer) and static polymorphism (based on template recursion & specialization, and policy driven classes) that is not necessarily based on base-to.derived inheritance, but still allow a clas to inherit something from another. And this -although existent- is not reflected in the proposed answer. The OOP concept of inheritance fits different programming formalism. C++ inheritance is just one of them. C++ embedding and delegating plays the same external effect. So, my point is: it depends if the word "inheritance" is meant to identify the way the object is internally made up (using class inheritance) or the way the object externally behave (exhibit the behavior of something else plus something more)
Sergey Alexandrovich Kryukov 25-Jul-11 19:32pm    
I know about different mechanisms, good point. However, I never heard about calling the relationship with member of the class an "inheritance" and think _Superman_ is right here.
In a way, polymorphism and late binding is more to the OOP then inheritance.
--SA
Emilio Garavaglia 27-Jul-11 3:11am    
Sure, but it is much more a matter of "convention" then substance.
OOP define what inheritance is. C++ provides a "tool" named class inheritance. Incidentally that was the only tool available in the first C++ standardization, and this made C++ programmers thinking the two concepts (defined independently each other and only partially isomorph) where the same. More tool had been added but ... the dear old convention survive.
There's nothing bad in it. Simply we must know it is a convention, not a physics constrain, making everything else impossible to exist.

I can define "objects" even with plain C struct-s containing function pointers, and inheritance as "responsibility chain".
Not something any "conventional" book on OOP will ever do, but technically getting the same result.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900