Chapter 16 Members Access Control
In C , users can explain the access level of member data and member functions. There are three access levels: public, protected and private. This chapter explains how access control is used for class type objects and derived classes.
This chapter includes the following topics:
* Access control of class members
* Access indicator
* Access indicator of the base class
* Friends
* Reserved member access
* Access to virtual functions
* Multiple visit
Access control of class members
By accessing access to class member data or function, users can increase the integrity of software prepared with C . Class members can explain that there is a private, protected or public access attribute, as shown in Table 10.1.
Table 10.1 Member Access Control
Access Type Meaning Private instructions for private class members can only be protected by this class member function or friend (class or function) to be protected by this class member function or friend ( Class or function) to use, and can also use public descriptions in such derived classes to use public members can be used in any function.
Access control prevents the user from being used without planning. This protection will lose its role when you explicitly use the type conversion.
Note: Access control is equivalent to all names. Includes: member functions, member data, nested classes, and enumerations.
Class type members in Class Keywords, class default access is private, and the default access to members of Struct and Union is public. For several cases, the current access level can be changed with public, private, and protected keywords.
Access indicator
In the class description, the member can have access indicators.
grammar
Access indicator: member table OPT
The access indicator determines the level of access to the name behind it, which has always affected the next access indicator or the end of the description. As shown in Figure 10.1 shows this concept.
Although only two access indicators are shown in Fig. 10.1, there is no limit to the number of access indicators in a given class description. For example, the class POINT in Figure 10.1 can be used free to use multiple access indicators as follows:
Class Point
{
PUBLIC: / / Description Public constructor
Point (int, int);
Private: // Describes the private state variable
INT_X;
PUBLIC: / / Description Public constructor
Point ();
PUBLIC: / / Description Public Accessor
INT & X (INT);
Private: // Describes the private state variable
INT _Y;
Public: / / Describe public accessor
INT & Y (int);
}
Note: As shown in the previous example, there is no special requirement for the order of the member access. The storage allocation of class type objects will be affected. However, members between access indicators will guarantee the allocation of the high-end growth of memory addresses.
Base class access indicator
There are two factors that control which base classes are visible in derived classes, and the same factor also controls access control of inheritance members in the derived class.
* Whether derived class is specified in the class head (Class-Head "Defined Type" in Chapter 8 "Class" in detail.
* Access control in the base class.
Table 10.2 gives the interaction of these factors and how to determine access to the base class member.
Table 10.2 Members in the base class Access
If the private protection is derived, if you are derived, if you use private derivation, if you use privately, if you use private derived, in derived class, if you use protection, it is derived in the derived class. If the protected derived, in the derived class is protected by public derived, in the derived class is protected in the derived class, in the derived class is public
The following example shows this:
Class Baseclass
{
PUBLIC:
INT publicfunc (); // shows public members
protected:
INT protctedfunc (); // Describes a protection member
Private:
INT PrivateFunc (); // Describes a private member
}
// Describe two classes derived from BaseClass
Class deivedClass1: Public Baseclass
{};
Class DerivedClass2: Private Baseclass
{}; In DeriveDClass1, member function publicfunc is a public function and protectedfunc is a protected member function because BaseClass is a public base class. PrivateFunc is a private member of BaseClass, and it is not accessible in any partner. In DeriveDClass2, functions publicfunc and protectedfunc are private members, because BaseClass is a private base class. The function privatefunc is a private member of Baseclass, which is irreparable in any part of the school.
Of course, you can explain a derived class without the base class access indicator. In this case, if the derived class's instructions use the Class keyword, the derived will be deemed to be private. If you use the struct keyword description, the derived is a public life, as follows:
Class Derived: base.
.
Equivalent to:
Class Derived: Private Base
...
Similarly, the following code:
Struct Derived: Base
...
Equivalent to:
Struct Derived: Public Base
...
Note that it is instructions for the private member to be inaccessible for functions or derived classes unless these functions or derived classes are used in the base class.
The combination type cannot have a base class.
Note: When explaining a private base class, it is recommended to explicitly use the Private keyword to enable the derived class to understand the member's access.
Access control and static members
When you explain that a base class is Private, it only affects non-statist members, and public static members are still accessible in derived classes. However, when using a pointer reference or object access base class member, it is necessary to conversion. At this point, the access control is still applicable, considering the following code:
Class Base
{
PUBLIC:
INT print (); // Non-static member
Static int countof (); // static member
}
// derived1 describes Base as a private base class
Class Derived1: Private Base
{
}
// derived2 explains DeriveD1 as a public base class
Class deived2: public deived1
{
Int showcount (); // Non-static member
}
/ / Define the showcount function of Derived2
INT Derived2 :: showcount ()
{
// Explicitly call static member functions countof
INT ccount = base :: countof (); // ok
// Call static member functions with pointer COUNTOF
ccount = this-> countof (); // error: Do not allow DeriveD2 * to Base *
Return ccount;
}
In the above code, access control suppresses the conversion from Derived2 * to Base *. The implicit type of the THIS pointer is Derived2 *. To select a Countof function, this must be converted to base *. This conversion is not allowed, because Base is the non-direct private base class of Derived2, converting a pointer of a derived class to pointing to its direct private base class, is allowed. Therefore, the pointer type derived1 * can be converted to base *.
Note, explicitly call the countof function without pointer, reference, or object, meaning that there is no conversion, thus calling is allowed.
Members or friends of the derived class T can convert a pointer to T-t-t-tap to the direct base class of T.
Friend
In some cases, the membership level of access control is paired with a non-book-based member function or when all functions in another individual class are more convenient. With Friend keywords, programmers can assign special functions or classes (all member functions in this class) not only access to public members, but also access to protected private members.
Friends function
The friend function is not considered a member of the class. It is still just an external function given special access. Friends are not in the range of classes, they do not have a member selector (. Or ->) to call unless they are members of other classes. The following example shows a Point class and an overload operator Operator (this example is mainly an example of a friend, not the overload operator. See Chapter 12 "Reserved" in Chapter 12 for details on the overload operator. Overload operator "section).
#include
// Description class PointClass Point
{
PUBLIC:
//Constructor
Point () {_x = _y = 0;}
Point (unsigned x, unsigned y) {_x = x; _y = y;
// Accessor
Unsigned x () {return _x;}
Unsigned y () {return_y;}
Void Print () {cout << "Point (" << _ x << "," << _ y << ")" << end1;}
// Friends function description
Friend Point Operator (Point & Pt, Int Noffset);
Friend Point Operator (int Noffset, Point & Pt);
Private:
Unsigned _x;
Unsigned _y;
}
// Friends function definition
//
// Handle Point Int expression
Point Operator (Point & Pt, Int Noffset)
{
Point PtTemp = Pt;
/ / Change the private member directly _x and _y
PTTEMP._X = Noffset;
PTTEMP._Y = Noffset;
Return PTTEMP;
}
// Process INT POINT Expression
Point Operator (int Noffset, Point & Pt)
{
Point PtTemp = Pt;
/ / Change the private member directly _x and _y
PTTEMP._X = Noffset;
PTTEMP._Y = Noffset;
Return PTTEMP;
}
// Test the overload operator
void main ()
{
Point PT (10, 20);
pt.print ();
Pt = Pt 3; // Point Int
pt.print ();
Pt = 3 pt; // int point
pt.print ();
}
When the compiler touches the expression PT 3 in the main function, the compiler confirms if there is a suitable user-defined Operator existence. In this case, the function operator (Point PT, INT Noffset matches the operator and issues calls to the function. In the second case (Expression 3 PT) function Operator (POINT PT, INT Noffset) matches the number of operands. Thus two forms of exchangeable modification of the operator is provided for Operator .
User-defined Operator functions can also be defined as a member function, but it can only receive an explicit parameter: add to the value in the object. As a result, the exchangeability of the use of member function adds cannot be implemented correctly. They must be replaced by friends to complete.
Note: Two versions of the overload Operator function illustrates the friend function in the class Point. Two instructions are necessary, and when the probiotiper name is overloaded, only those special functions illustrated by the parameter table will become a friend. Suppose the third Operator function is as follows:
Point & Operator (Point & Pt, Point & Pt)
The Operator function in the above example is not a Point's friend, but it has the same name with the other two instructions as the friend's function.
Because Friend explains that it is not subject to access indicators, they can be described in any section of the class description.
Class member functions and classes become friends
The class member function can be explained as a friend in other classes, considering the following example:
Class B
Class A
{
INT FUNC1 (B & B);
INT FUNC2 (B & B);
}
Class B
{
Private
INT_B;
Friend Int A :: Func1 (B &) // Give the friend access to class B
}; // one function in class B
Int a :: func1 (b) {return b._b;} // correct: This is a friend
INT A :: Func2 (B & B) {RETURN B._B;} // Error: _B is a private member
In the previous example, only the function A :: Func1 (B & B) gives the friend access to class B. Therefore, in the function FUNC1 in class A, it is correct. But FUNC2 is incorrect. Assuming that the friends in class B illustrate as follows:
FRIEND CLASS A; In this case, all member functions in class A have access to class B. Pay attention to "Friends Relations" is not inherited, and there is no visit to any "friend's friend". Figure 10.2 shows four classes descriptions: Base, Derived, Afriend and AnotherFriend. Only class AFRIEND is directly
Access to the rights of the private member of class base (and members inherited by class base).
Friend instructions
If you explain a friend function, and this function is previously explained, this function will export into a non-class enclosed block.
The function in the friend description is illustrated as Extern. Just like using the extern keyword (see "Static Storage Class Description" in Chapter 6, "Details on Extern".
The function in the global scope can be explained as a friend function before it is described, but the member function cannot be explained before its complete class instructions. The following code shows why failure:
Class forwardDeclared; // class name is knowclass Hasfriends {Friend Int ForwardDeclared :: isafriend (); // Error
}
The above examples, add the class name ForwardDec1Ares, but its complete definition is particularly the description of the function isafriend, so that the friend instructions in the class Hasfriends have an error.
In order to illustrate the two classes to be friends, the complete second class must explain the first class of friends. This limitation is why the compiler has sufficient information to specify a single friend function when the compiler is described only in the second class.
Note: Although the complete second class must explain the first class of friends, you can choose some of the functions in the first class becoming the second class.
Define a friend function in the class description
The friend function can be defined in the class description, these functions are embedded functions. As embedded, the act of embedded member functions, although they are defined after the desired class member and the end of the class (the end of the class description).
The friend function defined in the class description is considered to be in the file range, which is not in the closed class range.
Protected member access
Explain that a class member protected is for the following cases:
* The member of the member of the member is originally explained.
* Firstly, the member of the member's class is originally explained.
* Classs from public derived or categories that are initially visited by the member.
* Directly private derived class has private access to the protected members.
The protected member is different from the private member, as private members are only visible in their classes. The protected member is different from public members, as public members are accessible in any function.
Protection members illustrated with Static can be accessed by any friend function or a member of the derived class. Members who do not use Static description can also be accessed by any friend function or a member of the derived class, just through the object of derived class, point to the pointer of the derived class object, or the reference to the party object.
Visit of virtual functions
Access control for virtual functions is determined by the type of call to the virtual function. The instructions of the overload function do not have an impact on access control of a given class type, for example:
Class vfuncbase
{
PUBLIC:
Virtual int getState () {return _State;
protected:
Int_State;
}
Class vfuncderived: public vfuncbase
{
Private:
INT getState () {return _state;}
}
...
VFUNCDERIVED VFD; // Derived object
VFuncBase * pvfb = & vfd; // Pointer VFUNCDERIVED * PVFD = & vfd; // points to the pointer to the base class
Int State;
State = pvfb-> getState (); // getState is a public
State = pvfd-> getState (); // getState is private, error.
In the above example, use a pointer to type VFUNCBase to call the virtual function GetState to activate vfuncbase :: getState, and getState is used as a common, however, with a pointer to type VFUNCDERIVED to call GetState to destroy access control, because getState is in class The vFunderived is explained as private.
WARNING: Virtual Functions GetState can be called with a pointer to base class VFuncBase, which does not mean that the called function is which version of the base class.
Multiple visit
A virtual base class is involved in the framework of multiple inheritance. A given name can be reached by multiple paths. Different access controls are available in different ways, the compiler selection is the most desirable storage path, as shown in Figure 10.3.
In Figure 10.3, a name illustrated in class VBase can always be reached by class RightPath. The path on the right is always more accessible, because RightPath describes the VBASE as a common base class, and leftPath describes the VBASE as a private base class.
