MQL5에 OOP가 필요합니까? - 페이지 7

 

Подводя нектр. очень предварительные итоги, можно сказать, что ООП в реализации метаквотов даже опытными программерами не воспринята.

MQL5는 아직 게시되지 않았으며 이미 결과를 요약하고 있습니다. MQL4와 OOP가 없는 MQL5를 비교해봐도 그 차이는 확연합니다. 4개는 예를 들어 동일한 구조와 포인터와 같은 일반 언어의 기능이 부족했습니다. Petyarka는 모든 것을 갖추고 있습니다. 따라서 언어는 OOP가 없더라도 이전 버전보다 훨씬 강력합니다. 그리고 그 주제는 일반적으로 의미가 없습니다. OOP를 알고 사랑하는 사람들은 OOP로 코딩할 것이고, 독점적으로 절차적으로 코딩하는 사람들은 계속 이런 식으로 코딩할 것입니다. 질문의 본질은 무엇입니까?

 
C-4 >> :

MQL5는 아직 게시되지 않았으며 이미 결과를 요약하고 있습니다. MQL4와 OOP가 없는 MQL5를 비교해봐도 그 차이는 확연합니다. 4개는 예를 들어 동일한 구조와 포인터와 같은 일반 언어의 기능이 부족했습니다. Petyarka는 모든 것을 갖추고 있습니다. 따라서 언어는 OOP가 없더라도 이전 버전보다 훨씬 강력합니다. 그리고 그 주제는 일반적으로 의미가 없습니다. OOP를 알고 사랑하는 사람들은 OOP로 코딩할 것이고, 독점적으로 절차적으로 코딩하는 사람들은 계속 이런 식으로 코딩할 것입니다. 질문의 본질은 무엇입니까?


포인터가 없습니다. 그리고 구조가 있습니다.

 
HideYourRichess >> :

포인터가 없습니다.

교체가 있습니다.

 
TheXpert >> :

교체가 있습니다.

대체품이 있긴 한데 별로 맘에 안드네요. 어쩌면 내가 편견이 있습니다.

 
HideYourRichess >> :

대체품이 있긴 한데 별로 맘에 안드네요. 어쩌면 내가 편견이 있습니다.

따라서 가상 기능에 대한 목발이 분명합니다.

 
TheXpert >> :

따라서 가상 기능에 대한 목발이 분명합니다.

특히 주소 산술이 없다는 것을 고려할 때 이해할 수 있습니다.


사실, mt의 경우 이것은 매우 우수한 솔루션이며 많은 갈퀴를 제거합니다.

 

콜백을 위해 합법적 인 방법을 만드는 것이 좋습니다.

 
HideYourRichess писал(а) >>

콜백을 위해 더 나은 법적 방법을 수행하십시오.

우리는 볼 것이다

 
stringo >> :

우리는 볼 것이다

그러한 주제 이후 - 이것은 어떤 유형이며 어떻게 포인터(기술자)를 자체적으로 얻을 수 있습니까?

 
TheXpert писал(а) >>

그러한 주제 이후 - 이것은 어떤 유형이며 어떻게 포인터(기술자)를 자체적으로 얻을 수 있습니까?

안 돼요. 우리는 mql5 내부의 주소로 작업하지 않습니다. 이것은 포인터가 아니라 핸들이어야 합니다. 아마도 이것을 임시 핸들로 변환할 것입니다. 우리는 이것이 이루어져야 한다고 생각하는 경향이 있습니다.