BTW, 빌드 1325가 함수 에 대한 포인터를 도입했다는 것을 알고 있습니까? 그것이 삼각 커뮤니케이션을 적용하는 데 차이가 있습니까?
MQL5: 이벤트 모델의 배열을 단순화하기 위해 함수에 대한 포인터에 대한 지원이 추가되었습니다.
함수에 대한 포인터를 선언하려면 "함수에 대한 포인터" 유형을 지정합니다. 예를 들면 다음과 같습니다.
typedefint (*TFunc)( int , int );
이제 TFunc는 유형이며 함수에 대한 변수 포인터를 선언할 수 있습니다.
TFunc func_ptr;
func_ptr 변수는 나중에 선언하기 위해 함수 주소를 저장할 수 있습니다.
int sub( int x, int y) { return (x-y); }
int add( int x, int y) { return (x+y); }
int neg( int x) { return (~x); }
func_ptr=sub;
Print (func_ptr( 10 , 5 ));
func_ptr=add;
Print (func_ptr( 10 , 5 ));
func_ptr=neg; // error: neg is not of int (int,int) typePrint (func_ptr( 10 )); // error: there should be two parameters
함수에 대한 포인터를 저장하고 매개변수로 전달할 수 있습니다. 비정적 클래스 메서드에 대한 포인터를 가져올 수 없습니다.
OO 및 MQL5와 관련된 이벤트 모델 에 대한 이해가 부족한 것 같습니다. 이벤트를 전달하는 올바른 종류는 무엇입니까? 내 말은, 누가(어떤 클래스) 무엇(이벤트)을 받을지 어떻게 그리고 어디서 결정해야 하는지를 의미합니다. 최상위 디스패처, 언어 기본 디스패처, 즉 ::OnChartEvent 언어는 프로젝트의 최상위 클래스에서 한 번만 작성됩니다.
그렇다면 여기에서 이벤트를 다른 객체에 전달하는 올바른 방법은 무엇입니까? 디스패칭 이벤트 클래스가 있어야 합니까? if 문을 기반으로 ::OnChartEvent에서만 수행해야 합니까?
Amir Yacoby : OO 및 MQL5와 관련된 이벤트 모델에 대한 이해가 부족한 것 같습니다. 이벤트를 전달하는 올바른 종류는 무엇입니까? 내 말은, 누가(어떤 클래스) 무엇(이벤트)을 받을지 어떻게 그리고 어디서 결정해야 하는지를 의미합니다. 최상위 디스패처, 언어 기본 디스패처, 즉 ::OnChartEvent 언어는 프로젝트의 최상위 클래스에서 한 번만 작성됩니다.
그렇다면 여기에서 다른 객체에 이벤트를 전달하는 올바른 방법은 무엇입니까? 디스패칭 이벤트 클래스가 있어야 합니까? if 문을 기반으로 ::OnChartEvent에서만 수행해야 합니까?
이것은 전혀 질문이 아닙니다. OOP는 자연의 원리를 기반으로 합니다. 지구는 당신을 먹여 살리는 것이 아니라, 당신이 필요로 할 때, 언제, 어디서 무엇을 필요로 하는지 당신에게 달려 있습니다.
나는 그것을 할 수 있었지만 게시자와 청취자 사이의 계약이 아니므로 게시자는 청취자가 처리 방법을 가지고 있다고 가정해야했지만 강제하지는 않았습니다. 아니면 메인 리스너 객체에서 모든 리스너를 상속받아야 합니다. 하지만 다른 클래스를 상속할 수 없기 때문에 당연히 모든 요점을 잃게 됩니다.
여하튼, 나는 프로그래밍의 프로이지만 아직 경험이 부족한 OO에 있지 않으며 Doerk와 같은 경험 많은 oo 프로그래머와 경쟁하지 않습니다. 내가 알게 된 것은 절차적이라는 것이 좋은 논리와 프로그래밍 기술을 제공하지만 그 전환은 정신적으로 어렵다는 것입니다. 특히 나와 같은 절차 지향적인 사람이 OO 프레임워크 구축이라는 미션에 직면한다면 완전히 다른 마음가짐을 갖게 된다는 것입니다. 그리고 GUI 부분 프레임워크는 처리해야 할 많은 이벤트가 있는 가장 세부적인 프레임워크입니다. 프레임워크 중에서 빌드하기 가장 어렵다는 데 동의하실 것입니다.
BTW, 빌드 1325가 함수 에 대한 포인터를 도입했다는 것을 알고 있습니까?
그것이 삼각 커뮤니케이션을 적용하는 데 차이가 있습니까?
MQL5: 이벤트 모델의 배열을 단순화하기 위해 함수에 대한 포인터에 대한 지원이 추가되었습니다.
함수에 대한 포인터를 선언하려면 "함수에 대한 포인터" 유형을 지정합니다. 예를 들면 다음과 같습니다.
이제 TFunc는 유형이며 함수에 대한 변수 포인터를 선언할 수 있습니다.
func_ptr 변수는 나중에 선언하기 위해 함수 주소를 저장할 수 있습니다.
함수에 대한 포인터를 저장하고 매개변수로 전달할 수 있습니다. 비정적 클래스 메서드에 대한 포인터를 가져올 수 없습니다.
아마도 MT5에만 해당되며 내가 본 바로는 여전히 메서드가 아니라 기능에 대한 것입니다.
여하튼 나는 예를 들어 추세선 및 컨테이너의 컨텍스트에서 기본 클래스 내에서 타사 기능을 어떻게 정의하는지 여전히 이해하지 못합니다.
하지만 다시 읽어보려고 합니다.
내 말은, 누가(어떤 클래스) 무엇(이벤트)을 받을지 어떻게 그리고 어디서 결정해야 하는지를 의미합니다.
최상위 디스패처, 언어 기본 디스패처, 즉 ::OnChartEvent 언어는 프로젝트의 최상위 클래스에서 한 번만 작성됩니다.
그렇다면 여기에서 이벤트를 다른 객체에 전달하는 올바른 방법은 무엇입니까?
디스패칭 이벤트 클래스가 있어야 합니까? if 문을 기반으로 ::OnChartEvent에서만 수행해야 합니까?
OO 및 MQL5와 관련된 이벤트 모델에 대한 이해가 부족한 것 같습니다. 이벤트를 전달하는 올바른 종류는 무엇입니까?
내 말은, 누가(어떤 클래스) 무엇(이벤트)을 받을지 어떻게 그리고 어디서 결정해야 하는지를 의미합니다.
최상위 디스패처, 언어 기본 디스패처, 즉 ::OnChartEvent 언어는 프로젝트의 최상위 클래스에서 한 번만 작성됩니다.
그렇다면 여기에서 다른 객체에 이벤트를 전달하는 올바른 방법은 무엇입니까?
디스패칭 이벤트 클래스가 있어야 합니까? if 문을 기반으로 ::OnChartEvent에서만 수행해야 합니까?
알겠습니다. 알겠습니다. 절차적에서 oop로 넘어갈 때 개념 이동의 실제 문제가 있습니다.
사실 예전에 옵저버를 구현하고 싶었지만 MQL의 인터페이스 부족이나 다중 상속 때문에 구현하지 못했습니다. 동일한 개체가 인터페이스를 양쪽에 강제할 수 있다는 좋은 생각에 대해 생각하지 않았습니다.
그래서 실제로 각 CObject는 이제 이벤트의 수신자인 한 객체의 위치를 가지며 수신 객체가 구독하는 등록 메소드와 수신자가 사용하는 이벤트 발신자 메소드 및 이벤트 핸들러 메소드도 가지고 있습니다.
사실 예전에 옵저버를 구현하고 싶었지만 MQL의 인터페이스 부족이나 다중 상속 때문에 구현하지 못했습니다. 동일한 개체가 인터페이스를 양쪽에 강제할 수 있다는 좋은 생각에 대해 생각하지 않았습니다.
여러분을 격려하기 위해 저는 MQL4에서 리스너를 많이 사용해 왔습니다.
감사합니다. 하지만 용기가 나지 않습니다(:
나는 그것을 할 수 있었지만 게시자와 청취자 사이의 계약이 아니므로 게시자는 청취자가 처리 방법을 가지고 있다고 가정해야했지만 강제하지는 않았습니다.
아니면 메인 리스너 객체에서 모든 리스너를 상속받아야 합니다. 하지만 다른 클래스를 상속할 수 없기 때문에 당연히 모든 요점을 잃게 됩니다.
여하튼, 나는 프로그래밍의 프로이지만 아직 경험이 부족한 OO에 있지 않으며 Doerk와 같은 경험 많은 oo 프로그래머와 경쟁하지 않습니다.
내가 알게 된 것은 절차적이라는 것이 좋은 논리와 프로그래밍 기술을 제공하지만 그 전환은 정신적으로 어렵다는 것입니다. 특히 나와 같은 절차 지향적인 사람이 OO 프레임워크 구축이라는 미션에 직면한다면 완전히 다른 마음가짐을 갖게 된다는 것입니다. 그리고 GUI 부분 프레임워크는 처리해야 할 많은 이벤트가 있는 가장 세부적인 프레임워크입니다. 프레임워크 중에서 빌드하기 가장 어렵다는 데 동의하실 것입니다.