Zloy_Koldun : 귀하의 예에서 B는 Ct에 대한 액세스 권한이 있어야 하며 이를 금지할 이유가 없습니다.
당신은 둘 다 이상합니다. 클래스와 인스턴스를 혼동하고 있습니다. 나에게는 같은 클래스 B의 다른 인스턴스의 t에 대한 액세스가 없어야 합니다.
보호된 필드는 자체(B의 동일한 인스턴스, 즉 this)에서만 사용할 수 있어야 하고 다른 인스턴스(동일한 클래스 B의 경우에도)는 닫아야 합니다. 명확성을 위해 이름을 바꾸겠습니다.
class Человек
{
protected :
int кошелёк;
};
class Мужчина : public Человек
{
int fч( Человек& ч );
int fм( Мужчина& м );
};
int Мужчина::fч( Человек& ч ) // 1
{
кошелёк = 100 ; // Всё в порядке . моё.
int s = ч.кошелёк; // protected member access errorвполне справедливоreturn s;
}
int Мужчина::fм( Мужчина& м ) // 2
{
кошелёк = 100 ; // Всё в порядке , кошелёк мой собственный
int s = м.кошелёк; //это компилируется. и это НЕПРАВИЛЬНО!кошелёк ЧУЖОЙ !!
// С фига ли я должен иметь доступ к твоему кошельку, только на основании того что мы с тобой оба "Мужчины" ??
return s;
}
저것들. 나를 위해 - 첫 번째 함수뿐만 아니라 두 함수 모두 컴파일되어서는 안됩니다. C++에서 두 번째 것이 컴파일되고 작동한다면 이것은 미덕이 아니라 C++ 버그입니다.
간단히 말해서:
class Человек
{
protected :
int кошелёк;
public :
void Человек() { a= 3 ; }
void gч( Человек& ч )
{
ч.кошелёк--; // Даже это не должно компилироваться. не следует лазить в чужой кошелёк!
кошелёк++; // в свой можно
}
};
class Человек
{
private :
int кошелёк;
public :
void Человек() { кошелёк= 3 ; }
void gч( Человек& ч )
{
ч.кошелёк--; // сейчас работает. а не должно ;)
}
};
상속이 변경되면 분명합니다.
2. 누구에게나 필요한 것은 거의 없습니다. 이유는 자신의 사본에 액세스할 때만 있습니다.
프로필에서 서비스 데스크를 찾으십시오.
여기에는 모순이 없습니다. 그렇지 않으면 B는 아래와 같이 C.t에 액세스할 수 있지만 B는 C의 파생물이 아닙니다.
귀하의 예에서 B는 Ct에 대한 액세스 권한이 있어야 하며 이를 금지할 이유가 없습니다.
당신은 둘 다 이상합니다. 클래스와 인스턴스를 혼동하고 있습니다. 나에게는 같은 클래스 B의 다른 인스턴스의 t에 대한 액세스가 없어야 합니다.
보호된 필드는 자체(B의 동일한 인스턴스, 즉 this)에서만 사용할 수 있어야 하고 다른 인스턴스(동일한 클래스 B의 경우에도)는 닫아야 합니다. 명확성을 위해 이름을 바꾸겠습니다.
저것들. 나를 위해 - 첫 번째 함수뿐만 아니라 두 함수 모두 컴파일되어서는 안됩니다. C++에서 두 번째 것이 컴파일되고 작동한다면 이것은 미덕이 아니라 C++ 버그입니다.
간단히 말해서:
지갑과의 비교가 잘못되었습니다.
보호된 구성원에 대한 액세스가 필요한 예를 들 수 있지만 이는 나와 귀하의 선호 사항에 관한 것이 아닙니다.
프로그래머가 무언가를 금지하고 싶다면 스스로 할 수 있고 컴파일러는 금지해야 합니다.
프로그램을 깨뜨릴 수 있다면.
위의 예에서 클래스 B는 클래스 A에 대해 알고 있으므로 아무 것도 엉망으로 만들지 않습니다.
그리고 그것을 비활성화하려면 Private 섹션에 넣거나 한 클래스에서 상속하지 않거나 수천 가지 다른 방법을 생각하십시오.
저것들. 나를 위해 - 첫 번째 함수뿐만 아니라 두 함수 모두 컴파일되어서는 안됩니다. C++에서 두 번째 것이 컴파일되고 작동한다면 이것은 미덕이 아니라 C++ 버그입니다.
그러면 지갑에 대한 액세스도 거부됩니다.
다시 한 번: 클래스(유형)와 인스턴스(변수)를 주의 깊게 구별하십시오. 소유(이) 보호 필드는 상속할 때(비공개 필드와 달리)를 포함하여 자유롭게 사용할 수 있으며 외부(동일한 클래스의 다른 변수)는 사용할 수 없어야 합니다. (사용할 수 없어야 함)
.....
위의 예에서 클래스 B는 클래스 A에 대해 알고 있으므로 아무 것도 엉망이 되지 않습니다.
..............
지갑이 있다는 것을 안다고 해서 지갑에 접근할 이유가 없습니다. 당신에게 부탁합니다. 귀하에게 - get() 및 set()을 통해서만 - 허용하는 경우 (public: int get(); int set();).
지갑이 있다는 것을 안다고 해서 지갑에 접근할 이유가 없습니다. 당신에게 부탁합니다. 귀하에게 - get() 및 set()을 통해서만 - 허용하는 경우 (public: int get(); int set();).
지갑은 특별한 케이스일 뿐입니다. 그리고 아무도 그것을 사적인 부분에 넣는 것을 귀찮게하지 않습니다.
다른 경우에는 다른 개체의 부모 클래스변수에 액세스 해야 할 수도 있습니다.
그리고 그것을 허용할지 여부를 결정하는 것은 프로그래머에게 달려 있습니다. 그리고 컴파일러는 프로그램의 올바른 작동을 보장해야 합니다.
나는 모순의 예를 들었다 .. 객체는 동일하다
모순이 없습니다. "외부 인터페이스"를 통해 자신을 언급하는 경우 - 자신과 대면할 준비를 하십시오. ;)
........... 컴파일 시간에 ..에 대한 지식이 없기 때문 입니다.
1. 지갑은 특별한 케이스일 뿐입니다. 그리고 아무도 그것을 사적인 부분에 넣는 것을 귀찮게하지 않습니다.
2. 다른 경우에는 다른 개체의 부모 클래스 변수에 액세스 해야 할 수도 있습니다.
3. 그리고 그것을 허용할지 여부를 결정하는 것은 프로그래머에게 달려 있습니다.
4. 그리고 컴파일러는 프로그램의 올바른 작동을 보장해야 합니다.
1. 비공개 부분에 배치해도 다음과 같은 경우에는 변경되지 않습니다.
상속이 변경되면 분명합니다.
2. 누구에게나 필요한 것은 거의 없습니다. 이유는 자신의 사본에 액세스할 때만 있습니다.
3. 글쎄, 그가 결정하자. 바르게. ;)
4. 이것이 전체 질문입니다. 정확히 무엇이 "올바른 작업"으로 간주되는지입니다.