statics는 컨텍스트 확인 연산자를 통해 코드의 모든 섹션 에서 액세스할 수 있습니다. 일반적 으로 모든 ! (범위가 기억나지 않고 오랫동안 확인하지 않았지만 코드 맨 위에 설명 된 것처럼 전역 일 가능성이 큽니다. 즉, 정적 메서드가 어디에 있는지는 중요하지 않습니다. / 필드가 선언됨)
statics는 컨텍스트 확인 연산자를 통해 코드의 모든 섹션 에서 액세스할 수 있습니다. 일반적 으로 모든 ! (범위가 기억나지 않고 오랫동안 확인하지 않았지만 코드 맨 위에 설명 된 것처럼 전역 일 가능성이 큽니다. 즉, 정적 메서드가 어디에 있는지는 중요하지 않습니다. / 필드가 선언됨)
나는 논쟁할 준비가 되어 있지 않고 그러고 싶지도 않지만 정적 메서드의 동작은 도움말 텍스트에 해당합니다.
글쎄요, 인수로 확인할 필요가 없다고 생각하는 IMHO - MQL은 C#에서 프로그램의 동작을 향해 큰 걸음을 내딛고 있습니다. 프로그래머가 컨텍스트 확인 연산자를 사용하기로 결정한 것처럼 비슷한 상황이 있습니다. 그런 다음 그는 클래스에서 데이터 무결성 위반을 감지하기 위해 컴파일러의 도움을 의도적으로 거부합니다. 컨텍스트 확인 연산자 없이 메서드와 필드를 가져오는 고전적인 방법이 있습니다.
UPD: 조금씩 내 MQL 라이브러리를 다시 작성하기로 결정했습니다. 예약어 이름과 일치하는 인기 있는 MQL 코드의 메소드 및 필드 이름을 보고 작성하는 것을 보고 공포에 휩싸였습니다... IMHO 이것은 또한 다음을 향한 발걸음입니다. 종속성을 "분리"할 때 컴파일러의 도움을 거부합니다. ... 이와 같은 것 )))
어, 당신이 OOP를 피운 것 같아요, 휴식을 취하고 새로운 머리로. 컨텍스트 권한 연산자는 가시성을 정의하지만 어떤 식으로든 액세스에 영향을 미치지 않습니다.
글쎄, 나는 무엇을 피우고 언제 쉬어야할지 스스로 결정합니다)))
추신: 메모리 내용에 액세스할 수 있는 모든 언어에는 항상 많은 트릭이 있습니다. habr 저는 파이썬에 대한 주석에서 일반 강판을 읽었습니다. 글쎄, 그러면 결국 얻은 것에 대해 죄를 짓지 마십시오. 컴파일러는 항상 접근해서는 안되는 위치에 들어갈 수 있습니다. )))
모르겠습니다. 몇 달 전에 @Ilyas 관리자가 정적 초기화 순서를 설명하고 MQL 프로그램을 시작할 때 정적 메서드와 정적 필드가 전역 변수와 함께 초기화된다고 언급했습니다. . 그런 다음 그의 메시지를 검색하십시오.
나는 논쟁할 준비가 되어 있지 않고 그러고 싶지도 않지만 정적 메서드의 동작은 도움말 텍스트에 해당합니다.
글쎄요, 인수로 확인할 필요가 없다고 생각하는 IMHO - MQL은 C#에서 프로그램의 동작을 향해 큰 걸음을 내딛고 있습니다. 프로그래머가 컨텍스트 확인 연산자를 사용하기로 결정한 것처럼 비슷한 상황이 있습니다. 그런 다음 그는 클래스에서 데이터 무결성 위반을 감지하기 위해 컴파일러의 도움을 의도적으로 거부합니다. 컨텍스트 확인 연산자 없이 메서드와 필드를 가져오는 고전적인 방법이 있습니다.
UPD: 조금씩 내 MQL 라이브러리를 다시 작성하기로 결정했습니다. 예약어 이름과 일치하는 인기 있는 MQL 코드의 메소드 및 필드 이름을 보고 작성하는 것을 보고 공포에 휩싸였습니다... IMHO 이것은 또한 다음을 향한 발걸음입니다. 종속성을 "분리"할 때 컴파일러의 도움을 거부합니다. ... 이와 같은 것 )))
클래스 멤버를 정적으로 선언할 수 없으면 프로그램의 전역 수준에서 이 데이터를 선언해야 합니다. 이것은 데이터와 해당 클래스 간의 관계를 깨뜨릴 수 있으며, 데이터 클래스와 데이터를 처리하는 방법의 조합인 주요 OOP 패러다임과도 일치하지 않습니다. 정적 멤버를 사용하면 단일 인스턴스에 고유하지 않은 클래스 데이터가 클래스 범위에 존재할 수 있습니다.
https://www.mql5.com/ru/docs/basis/oop/staticmembers
?
?
예에 정적 수정자가 있습니다. 제거하면 컴파일러에서 예상대로 경고를 발행합니다.
statics는 컨텍스트 확인 연산자를 통해 코드의 모든 섹션 에서 액세스할 수 있습니다. 일반적 으로 모든 ! (범위가 기억나지 않고 오랫동안 확인하지 않았지만 코드 맨 위에 설명 된 것처럼 전역 일 가능성이 큽니다. 즉, 정적 메서드가 어디에 있는지는 중요하지 않습니다. / 필드가 선언됨)
statics는 컨텍스트 확인 연산자를 통해 코드의 모든 섹션 에서 액세스할 수 있습니다. 일반적 으로 모든 ! (범위가 기억나지 않고 오랫동안 확인하지 않았지만 코드 맨 위에 설명 된 것처럼 전역 일 가능성이 큽니다. 즉, 정적 메서드가 어디에 있는지는 중요하지 않습니다. / 필드가 선언됨)
오랜만이네요 :)
모든 동일한 규칙(비공개, 보호됨, 공개)이 정적에 적용 되며 .
여기에는 명백한 버그가 있습니다.
오랜만이네요 :)
모르겠습니다. 몇 달 전에 @Ilyas 관리자가 정적 초기화 순서를 설명하고 MQL 프로그램을 시작할 때 정적 메서드와 정적 필드가 전역 변수와 함께 초기화된다고 언급했습니다. . 그런 다음 그의 메시지를 검색하십시오.
모든 동일한 규칙(비공개, 보호됨, 공개)이 정적에 적용 되며 .
여기에는 명백한 버그가 있습니다.
나는 논쟁할 준비가 되어 있지 않고 그러고 싶지도 않지만 정적 메서드의 동작은 도움말 텍스트에 해당합니다.
글쎄요, 인수로 확인할 필요가 없다고 생각하는 IMHO - MQL은 C#에서 프로그램의 동작을 향해 큰 걸음을 내딛고 있습니다. 프로그래머가 컨텍스트 확인 연산자를 사용하기로 결정한 것처럼 비슷한 상황이 있습니다. 그런 다음 그는 클래스에서 데이터 무결성 위반을 감지하기 위해 컴파일러의 도움을 의도적으로 거부합니다. 컨텍스트 확인 연산자 없이 메서드와 필드를 가져오는 고전적인 방법이 있습니다.
UPD: 조금씩 내 MQL 라이브러리를 다시 작성하기로 결정했습니다. 예약어 이름과 일치하는 인기 있는 MQL 코드의 메소드 및 필드 이름을 보고 작성하는 것을 보고 공포에 휩싸였습니다... IMHO 이것은 또한 다음을 향한 발걸음입니다. 종속성을 "분리"할 때 컴파일러의 도움을 거부합니다. ... 이와 같은 것 )))
Igor Makanu :
프로그래머가 컨텍스트 확인 연산자를 사용하기로 결정한 경우 클래스에서 데이터 무결성 위반을 감지하기 위해 컴파일러의 도움을 의도적으로 거부하는 것처럼 컨텍스트 확인 연산자 없이 메서드와 필드를 가져오는 고전적인 방법이 있습니다.
어, 당신이 OOP를 피운 것 같아요, 휴식을 취하고 새로운 머리로. 컨텍스트 권한 연산자는 가시성을 정의하지만 어떤 식으로든 액세스에 영향을 미치지 않습니다.
어, 당신이 OOP를 피운 것 같아요, 휴식을 취하고 새로운 머리로. 컨텍스트 권한 연산자는 가시성을 정의하지만 어떤 식으로든 액세스에 영향을 미치지 않습니다.
글쎄, 나는 무엇을 피우고 언제 쉬어야할지 스스로 결정합니다)))
추신: 메모리 내용에 액세스할 수 있는 모든 언어에는 항상 많은 트릭이 있습니다. habr 저는 파이썬에 대한 주석에서 일반 강판을 읽었습니다. 글쎄, 그러면 결국 얻은 것에 대해 죄를 짓지 마십시오. 컴파일러는 항상 접근해서는 안되는 위치에 들어갈 수 있습니다. )))
모르겠습니다. 몇 달 전에 @Ilyas 관리자가 정적 초기화 순서를 설명하고 MQL 프로그램을 시작할 때 정적 메서드와 정적 필드가 전역 변수와 함께 초기화된다고 언급했습니다. . 그런 다음 그의 메시지를 검색하십시오.
나는 논쟁할 준비가 되어 있지 않고 그러고 싶지도 않지만 정적 메서드의 동작은 도움말 텍스트에 해당합니다.
" private - 이 클래스의 메서드에서만 클래스 변수 및 메서드에 대한 액세스를 허용합니다. "
"만"이라는 단어가 명확하지 않은 곳은 어디입니까?
예제에 따르면 OnStart는 클래스 A 메서드가 아닙니다.
" private - 이 클래스의 메서드에서만 클래스 변수 및 메서드에 대한 액세스를 허용합니다. "
"만"이라는 단어가 명확하지 않은 곳은 어디입니까?
예제에 따르면 OnStart는 클래스 A 메서드가 아닙니다.
private modifier가 아니라 static modifier 에 대한 것입니다. 테스트를 하고 MQL에서 static이 어떻게 동작하는지 확인하세요.
모르겠습니다. 몇 달 전에 @Ilyas 관리자가 정적 초기화 순서를 설명하고 MQL 프로그램을 시작할 때 정적 메서드와 정적 필드가 전역 변수와 함께 초기화된다고 언급했습니다. . 그런 다음 그의 메시지를 검색하십시오.
나는 논쟁할 준비가 되어 있지 않고 그러고 싶지도 않지만 정적 메서드의 동작은 도움말 텍스트에 해당합니다.
글쎄요, 인수로 확인할 필요가 없다고 생각하는 IMHO - MQL은 C#에서 프로그램의 동작을 향해 큰 걸음을 내딛고 있습니다. 프로그래머가 컨텍스트 확인 연산자를 사용하기로 결정한 것처럼 비슷한 상황이 있습니다. 그런 다음 그는 클래스에서 데이터 무결성 위반을 감지하기 위해 컴파일러의 도움을 의도적으로 거부합니다. 컨텍스트 확인 연산자 없이 메서드와 필드를 가져오는 고전적인 방법이 있습니다.
UPD: 조금씩 내 MQL 라이브러리를 다시 작성하기로 결정했습니다. 예약어 이름과 일치하는 인기 있는 MQL 코드의 메소드 및 필드 이름을 보고 작성하는 것을 보고 공포에 휩싸였습니다... IMHO 이것은 또한 다음을 향한 발걸음입니다. 종속성을 "분리"할 때 컴파일러의 도움을 거부합니다. ... 이와 같은 것 )))
https://pikabu.ru/story/nevozmozhno_tak_nevozmozhno_2129852
?
이상한 상황, 클래스 외부의 모든 것이 오랫동안 정적 작업으로 작업되었습니다. 여기 십자가에 못 박고 있습니다 .... 재미를 위해 직접 코드를 재현해 보세요.
개체 인스턴스가 보이나요? ... 그리고 그것은 MQL에 있습니다 ;)
추신: 그리고 참조 수준에서 ... 나에게 주장하는 것은 무엇입니까?
https://www.mql5.com/ru/docs/basis/oop/staticmembers
클래스 멤버를 정적으로 선언할 수 없으면 프로그램의 전역 수준에서 이 데이터를 선언해야 합니다. 이것은 데이터와 해당 클래스 간의 관계를 깨뜨릴 수 있으며, 데이터 클래스와 데이터를 처리하는 방법의 조합인 주요 OOP 패러다임과도 일치하지 않습니다. 정적 멤버를 사용하면 단일 인스턴스에 고유하지 않은 클래스 데이터가 클래스 범위에 존재할 수 있습니다.