오류, 버그, 질문 - 페이지 1055

 
zfs :
프로필에서 서비스 데스크를 찾으십시오.
덕분에!
 
A100 :
여기에는 모순이 없습니다. 그렇지 않으면 B는 아래와 같이 C.t에 액세스할 수 있지만 B는 C의 파생물이 아닙니다.
귀하의 예에서 B는 Ct에 대한 액세스 권한이 있어야 하며 이를 금지할 이유가 없습니다.
 
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ч( Человек& ч )
   {
    ч.кошелёк--;   // Даже это не должно компилироваться.  не следует лазить в чужой кошелёк!
    кошелёк++;    // в свой можно
   }   
};
 

지갑과의 비교가 잘못되었습니다.

보호된 구성원에 대한 액세스가 필요한 예를 들 수 있지만 이는 나와 귀하의 선호 사항에 관한 것이 아닙니다.

프로그래머가 무언가를 금지하고 싶다면 스스로 할 수 있고 컴파일러는 금지해야 합니다.

프로그램을 깨뜨릴 수 있다면.

위의 예에서 클래스 B는 클래스 A에 대해 알고 있으므로 아무 것도 엉망으로 만들지 않습니다.

그리고 그것을 비활성화하려면 Private 섹션에 넣거나 한 클래스에서 상속하지 않거나 수천 가지 다른 방법을 생각하십시오.

 
MetaDriver :


저것들. 나를 위해 - 첫 번째 함수뿐만 아니라 두 함수 모두 컴파일되어서는 안됩니다. C++에서 두 번째 것이 컴파일되고 작동한다면 이것은 미덕이 아니라 C++ 버그입니다.

그러면 지갑에 대한 액세스도 거부됩니다.
Человек ч;
ч.gч( ч );
 
A100 :
그러면 지갑에 대한 액세스도 거부됩니다.

다시 한 번: 클래스(유형)와 인스턴스(변수)를 주의 깊게 구별하십시오. 소유(이) 보호 필드는 상속할 때(비공개 필드와 달리)를 포함하여 자유롭게 사용할 수 있으며 외부(동일한 클래스의 다른 변수)는 사용할 수 없어야 합니다. (사용할 수 없어야 함)

Zloy_Koldun :
.....

위의 예에서 클래스 B는 클래스 A에 대해 알고 있으므로 아무 것도 엉망이 되지 않습니다.

..............

지갑이 있다는 것을 안다고 해서 지갑에 접근할 이유가 없습니다. 당신에게 부탁합니다. 귀하에게 - get() 및 set()을 통해서만 - 허용하는 경우 (public: int get(); int set();).

 
MetaDriver :


protected는 컴파일할 때 객체에 대한 정보가 없기 때문에 객체 수준이 아니라 클래스 수준에서 액세스를 제한합니다. 나는 모순의 예를 들었다
Человек ч;
ч.gч( ч );
개체는 동일
 
MetaDriver :

지갑이 있다는 것을 안다고 해서 지갑에 접근할 이유가 없습니다. 당신에게 부탁합니다. 귀하에게 - get() 및 set()을 통해서만 - 허용하는 경우 (public: int get(); int set();).

지갑은 특별한 케이스일 뿐입니다. 그리고 아무도 그것을 사적인 부분에 넣는 것을 귀찮게하지 않습니다.

다른 경우에는 다른 개체의 부모 클래스변수에 액세스 해야 할 수도 있습니다.

그리고 그것을 허용할지 여부를 결정하는 것은 프로그래머에게 달려 있습니다. 그리고 컴파일러는 프로그램의 올바른 작동을 보장해야 합니다.

Документация по MQL5: Основы языка / Переменные
Документация по MQL5: Основы языка / Переменные
  • www.mql5.com
Основы языка / Переменные - Документация по MQL5
 
A100 :
나는 모순의 예를 들었다 .. 객체는 동일하다

모순이 없습니다. "외부 인터페이스"를 통해 자신을 언급하는 경우 - 자신과 대면할 준비를 하십시오. ;)

........... 컴파일 시간에 ..에 대한 지식이 없기 때문 입니다.

 
Zloy_Koldun :

1. 지갑은 특별한 케이스일 뿐입니다. 그리고 아무도 그것을 사적인 부분에 넣는 것을 귀찮게하지 않습니다.

2. 다른 경우에는 다른 개체의 부모 클래스 변수에 액세스 해야 할 수도 있습니다.

3. 그리고 그것을 허용할지 여부를 결정하는 것은 프로그래머에게 달려 있습니다.

4. 그리고 컴파일러는 프로그램의 올바른 작동을 보장해야 합니다.

1. 비공개 부분에 배치해도 다음과 같은 경우에는 변경되지 않습니다.

 class Человек
{
private :
   int кошелёк; 
public :
   void Человек() {  кошелёк= 3 ; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // сейчас работает.  а не должно ;)
   }
};

상속이 변경되면 분명합니다.

2. 누구에게나 필요한 것은 거의 없습니다. 이유는 자신의 사본에 액세스할 때만 있습니다.

3. 글쎄, 그가 결정하자. 바르게. ;)

4. 이것이 전체 질문입니다. 정확히 무엇이 "올바른 작업"으로 간주되는지입니다.