I was looking at inheritance concepts in http://www.geeksforgeeks.org/inheritance-in-c/. I was confused with few sentences written by the author. At one place author says
If we derive a sub class from a public base class. Then the public
member of the base class will become public in the derived class .......
That means do we have something like public class in C++? Also below table from the article indicates that there is a concept of public/Protected class.
I looked at few other SO posts (Use of "Public" in a derived class declaration?) and found no reference to Public, Private or protected class itself. The post https://stackoverflow.com/questions/4792614/making-classes-public-to-other-classes-in-c talks of public, but by means of header file.
The Public, Protected and Private keywords are the visibility labels in C++. There is no public, protected and private class type in c++ (like Java). These three keywords are also used in a completely different context to specify the visibility inheritance model.
The table given below lists all of the possible combinations of the component declaration and inheritance model presenting the resulting access to the components when the subclass is completely defined.
It reads in the following way (take a look at the first row):
if a component is declared as public and its class is inherited as
public the resulting access is public.
Have a look at an example below:
class Super {
private: int x;
protected: int y;
public: int z;
};
class Sub : protected Super {};
The resulting access for variables y, z in class Sub is protected and for variable x is none.
NOTE:
The lack of a modifier yields private.
Related
In vscode how to check if a method is private, public or protected in editor?
If there is a solution to show this in outline that will help too.
EDIT: I can check the header file to see access level, but I want to see it in cc file in popup or in outline.
C++ access is defined by sections.
A class example
class Example{
public:
//anything that is public goes here
protected:
//anything protected goes here
private:
//anything private goes here
};
The default access is private.
You do not need to write all of these sections, nor in this order but it is generally good to write it like this public, protected, private.
It doesn't matter if you are in vscode, visual studio or code::blocks, the editor itself doesn't affect the code.
To access methods and fields from class you have 3 options
Public members can be access everywhere
Protected members act like private for every other scenario except for inherited classes. The classes that inherit base class can access protected fields and methods.
Private members of the class can only be accessed by that class itself.
If a class is inherited in public mode so public members and protected members of base class will go in public and protected section of derivied class.
My question is: if there is no protected section in derived class then what will happen?
Nothing will "happen". The class simply will not have protected members other than those of its base(s).
If you don't write protected:, that doesn't mean the class is incapable of having [inherited] protected members, or that it has no "protected section". Syntax and semantics are not that tightly coupled.
With public inheritance, it does not matter if derived class has no protected section at all in its definition, or if it is empty. The protected members of base class are inherited anyway and remain protected. Same for public, even if derived class has no public section in its definition.
The public:/protected:/private: in calss definitions are not really "sections", they are just syntax to mark member access for the members following them until the next public:/protected:/private:, and you can have any number of such "sections" in any order.
So I was just happily going along defining a new class when this happend:
class Thing : public OtherThing
{
public:
Thing : public OtherThing();//here
};
I really have no idea why visual assist/studio did this and i've never seen it before so really my question is what does it mean?
Just for the sake of clarity I would normally define the same class like this:
class Thing : public OtherThing
{
public:
Thing();
};
The public keyword is defined in 2 contexts:
Deferring access to members of a base class to the access level they were declared with:
When a class uses public member access specifier to derive from a base, all public members of the base class are accessible as public members of the derived class and all protected members of the base class are accessible as protected members of the derived class (private members of the base are never accessible unless friended)[source]
Specifying the access level for all members declared following this specifier
Public members form a part of the public interface of the class (other parts of the public interface are the non-member functions found by Argument-Dependent Lookup).
A public member of a class is accessible everywhere.[source]
Since the code you have demonstrated is not declaring inheritance (1) or specifying member access (2) it is an invalid use of the keyword and should not compile.
I see your statement that this compiles for you, but indeed this cannot compile in gcc: http://ideone.com/Z33viJ or in Visual Studio 2015, which you can validate by going here: http://webcompiler.cloudapp.net/ The only plausible explanation that I can come up with is there is a malfunction in which the code your editor is showing you is not what has been written to the file and thus is not what's being compiled. If this is the case perhaps a restart of Visual Studio would solve the problem.
I've got some confusions on the access level in C++ inheritance and more generally how I should design a C++ class.
class Car
{
public:
private:
string brandName;
}
class Sedan: public Car
{
public:
// this function needs to know the Sedan's brandName
void someFun()
{
brandName = "sss"; // error!!!
}
private:
}
In the above example the Car as a base class has a private member "brandName", and the Sedan as a derived class from Car inherits that member "brandName". As explained in Effective C++, public inheritance makes an "is-a" relationship, which means Sedan is a Car, now can I say that Sedan has a "brandName"?. If the answer is yes, why couldn't Sedan access to its own attribute in someFun?
I know the solution is to change brandName's access level to protected, my confusion is that what features or conditions make a variable member to which access level, in other word how I decide which access level should a given member be attached to?
I'd also like it if you'd recommend any book or article elaborating on this topic.
now can I say that Sedan has a "brandName"?
No, neither has Car. The brandName is an implementatin detail, private, hidden from anyone else and does not contribute to the class' public interface, which is what makes the nature of a Car. So while technically there is a brandName somewhere in a Car and thus in a Sedan, from a pure OO view that does not matter. Similar to "Is-A"-relationships that are expressed only by public inheritance and not by private inheritance, "Has-A"-relationships in the OO point of view are only present if the composition or assoctiation is publicly accessible/visible (mostly via getters/setters).
juanchopanza's answer and the comments to it have lead me to sneak a little around the web, trying to find resources about Is-A and Has-An relationships. this transcription seems to indicate that the two terms did not originate from OO thoughts. In fact, OO literature seems to cite the Liskov Substitution Principle instead of using "Is-A" relationships. It lays stress on encapsulation and opaque objects, so it concerns mostly with public interfaces of classes and how their behavior affect associated objects. While a "Has-A" relationship can be association, it also can be aggregation. In this case, since the brandName is not an external, associated object (in C++ we would express that fact with a pointer or reference member), it is an aggregation-"Has-A", hidden in the opaque Car and therefore not of interest for OO (and the above answer is left semantically valid).
I know the solution is to change brandName's access level to protected
NO! brandName's access level has to remain private, so that Car has the complete control over what happens to it. If you want to access it in derived classes, provide protected getters and/or setters.
I'd also like it if you'd recommend any book or article elaborating on this topic.
Any book about object oriented design should do. If you read through two or more of them, you will get a good idea of what to do and what not to do.
can I say that Sedan has a "brandName"?.
Yes, it certainly has an object of type string called Car::brandName (whether this constitutes an OOP "has-a" relationship isn't entirely clear to me, but probably not: see comments)
If the answer is yes, why couldn't Sedan access to its own attribute in someFun?
Simple because brandName is private. Those are the rules of the language. If you want to give a derived class access to a non-public data member, you can make it protected.
I'd also like it if you'd recommend any book or article elaborating on this topic.
There is a list of books here. Perhaps "The C++ Programming Language" would be good for explaining this particular aspect.
you have hidder brandName from the outer world, by making it private. Make it protected so that children may inherit it. To understand inheritance rules regarding specifiers, go to HERE
Public members are free to all to use.
Private members are for the use of only this current class, and no one else. It is used mostly for inner members of the class to use and save for it's own purposes or to provide a method to access to them.
Protected members are accessible for inherited classes, just as your example shows - brandName is for the use of inherit classes, so it should be protected.
I've got some confusions on the access level in C++ inheritance and more generally how I should design a C++ class.
C++ has three access level specifiers that can be used when inheriting:
private, protected and public
class Derived : public Base
Is called public inheritance and represents IsA relationship. When inheriting publicly, public members of the base remain public in Derived, protected members remain protected in Derived and private members are private (and not accessible from Derived).
class Derived : protected Base
Is called protected inheritance. This kind of inheritance is rare, and would be used if you don't want to expose the public part of Base when accessed as derived (or through the interface of Derived). In this kind of inheritance the public members in base become protected in derived.
Also see the C++ FAQs
class Derived : private Base
Is called private inheritance. This kind of inheritance can be used to simulate containment (Herb Sutter - Uses and abuses of inheritance). Here public members in Base become private when accessed through the interface of derived.
It can also be noted that protected and private inheritance does not represent the classic IsA relationship. The following polymorphic behaviour is only possible when inheriting publicly:
Derived d;
Base* b = &d;
However, for private inheritance polymorphic behaviour is possible in the first derived class (but not in subsequent).
struct Base{};
struct Derived : private Base
{
Derived()
{
//IsA holds within member functions of Derived, but not
// outside
Base* b = this;
}
};
struct Derived2 : public Derived
{
Derived2()
{
Base* b = this; //Fails to compile...inaccessible base
}
};
int main()
{
Derived d;
Base* b = &d; //Fails to compile
}
For protected inheritance polymorphic behaviour is possible in the all subsequent derived classes (Therefore code in constructor of Derived2 here above would compile), but not outside of class member functions.
Herb Sutter comments on reasons for using non public inheritance in Uses and abuses.
Finally, a comment concerning your example above: Usually Car would be abstract (an interface, consisting only of pure virtual functions), and therefore it would not contain any data members, but leave it open to the implementation. This is a guideline concerning inheritance that I've heard somewhere Sutter - Exceptional C++:
Inherit publicly in order to be reused by code that uses base classes polymorphically.
Your example would/could become:
struct Car
{
//Note: const used as brandName should not modify logical state.
virtual const std::string& brandName() const = 0;
//...virtual ~Car(), amongst others, depending
// on whether you intend to be deleted via this interface...
};
// Note: public inheritance implied by struct
struct CarFromFile: /*public*/ Car
{
CarFromFile( std::ifstream& file )
: brandName_( strFrom( file ) ),
manufacturer_( strFrom( file )
{
}
virtual const std::string& brandName() const{ return brandName_; }
private:
std::string strFrom( std::ifstream& file )
{
std::string value;
if( file >> value ) { return value; }
throw std::runtime_error( "Invalid file format!" );
}
std::string brandName_;
std::string manufacturer_;
//etc...
};
The fact that you make the accessor abstract, allows freedom from
the perspective of the implementer of derived, and defines the service
required by the client of base, independent of how the actual data looks.
The classifications for public, protected and private are intended to allow one to separate publicly available interfaces from internal implementation details. Thus, things that are not public are inaccessible, forcing users of the class to use the public interfaces provided.
If something is private, then even though inheritance will make the member a part of the derived class, the derivation is not allowed to access it. If it is desirable to allow a derived class access to interfaces and members that are not part of the public interface, then that is exactly when to use protected.
Well there is enough information about this subject. For example this thread was very clear to me: Difference between private, public, and protected inheritance
Except one point; Why is it useful?
Use public inheritance to reflect an is-a relationship. This is the main use for inheritance, especially in combination with virtual functions. It allows re-use of interface, not just of old code by new code, but also re-use of new code by old code! (because of virtual function dispatch at runtime).
In exceptional circumstances, use private inheritance to reflect an is-implemented-in-terms-of relationship. This is a commonly overused pattern, often the equivalent goal can be reached through composition (having the would-be base class as a data member). Another drawback is that you can easily have multiple inheritance of the same base class (twice or more removed) leading to the so-called Diamond Problem.
Avoid using protected inheritance, it suggest that your class interface is client-dependent (derived classes versus the world). Often this is due to classes having multiple responsiblities, suggesting a refactoring into separate classes is appropriate.
The answer to this question concerns class interfaces and data encapsulation, rather than language capabilities.
The use cases of protected and private inheritance are rather limited, since there are often other options available which better solve the problem (such as using composition, rather than inheritance). However, there are times when you necessarily must inherit from some type (for example to interface with a third-party library), but you would strongly prefer (for reasons related to user interface of your class) to hide most members inherited from the base class from the users of your new type. A typical scenario would be when you need your type to have the member functions of a certain class for internal use, but it would break the logic of your new type if it was called from outside the class itself.
In these situations, you need to use private or protectedinheritance (depending on whether the interface should be similarly restricted to further derived classes or not.
Bear in mind, however, that this is all just about (strongly) hinting to the users of your class how they should use it. You're adapting its public interface to hide certain features which were public in its base class. This doesn't strictly speaking prevent people from accessing these members, since anyone can still cast a pointer to your derived class to a pointer to the base, and reach the "hidden" resources that way.
It's all about Data Encapsulation.
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
Encapsulation concept
It is good to protect your classes 'internal' data from other classes. Benefits include:
other classes have to go through the known proper access mechanisms (e.g. methods) to access your class and can't monkey around with the internals of your class directly (and hence potentially put your class into some unknown and broken state)
you can change the inner workings of your class and know that other classes won't break as a result
reducing visible external points of contact with a class makes your classes simpler to use and understand
Having the option of using protected instead of private also makes your code easier to extend through subclassing.
Private: private members of a class can be accessed only from class functions, constructors, and destructors. The client who will use your class will be unable to access them. So, if for example you are implementing a list class and you want to keep track of the list's size, then you should have a private variable (listSizeP for example). You do this because you don't want the client to be able to modify the size of the list without inserting elements.
Public: public members can also be accessed by the client. In the list example mentioned above, functions like insert and erase should be public.
Protected: protected members of a class, like private members, can be accessed only from class functions, but they can also be accessed by classes inherited by this class(actually it depends on the way the derived class inherits the base. If it is not public inheritance, then the derived class cannot access the private members of the base class. That's why the most common way of inheriting is public inheritance). Example:
#include <iostream>
using namespace std;
class Base {
public:
int num;
public:
Base(int x=0) : num(x) {}
};
class Derived : public Base {
public:
Derived(int x=0) : Base(x) {}
void tell() { cout << "num: " << num << endl; }
};
int main() {
Derived D(4);
D.tell(); // would cause error if num was private
return 0;
}