MQL로 문명화된 라이브러리를 작성한 다음 이야기하겠습니다. 이 비명은 몇 년 동안 들렸고, 그것이 나오자 마자 솔직한 바이들로코딩이 시작됩니다.
CObject MQ의 참조가 정말 엉망입니다. 그들은 거기에 있어서는 안됩니다. 그리고 이러한 링크는 CList와 같은 매우 특정한 컨테이너에서 사용됩니다. 그러나 어디에 실수가 있습니까? 당신은 문명 언어를 구사합니까? 같은 Richter에 대한 비판, 그가 Object C #에 대해 어떻게 생각하는지, 그리고 그의 의견으로는 그 안에 있으면 안 되는 방법을 읽으십시오. 리히터가 옳기 때문에 C# 사용을 중단해야 합니까? 날뛰다. 그러니 여기에서 쌓이는 것을 멈추고 마침내 절차상의 정글로 가십시오.
그러나 동시에 CObject의 기능을 지속적으로 사용하고 비평가 중 누구도 표준 라이브러리의 개체, 배열 및 목록과 유사한 것을 제공하지 않았습니다.
"How to do it"은 모든 사람이 고함치는 방식입니다. 그러나 무언가를 제공하기 위해 - 갑자기 아무것도 없습니다.
실제로 다양한 소프트웨어 솔루션을 제공하는 참가자(CObject'y의 대체품을 제공하지 않음)조차도 "한 곳을 통한 구현"에 주의를 기울이지 않고 더 자주 사용하지 않고 기능을 덜 사용합니다. 따라서 구현 자체에 매우 적합합니다.
그것이 나빴다면 그들은 오래 전에 교체를 제안했을 것입니다.
글쎄, 일반적으로 일반 CObject는 다른 모든 것도 표준 라이브러리 를 기반으로 할 때 사용됩니다. 특히, 자신의 소스 코드를 적극적으로 공유하는 사람들은 일반적으로 타사 사용자의 삶을 더 쉽게 만들기 위해 통합하고 자체 작성 코드를 줄이고 자체 라이브러리 수를 줄이는 경향이 있습니다. 그러나 여기서 모든 사람은 자신을 위해 인코딩할지 아니면 다른 사람의 편의를 위해 인코딩할지 스스로 결정합니다.
그래서 많은 사람들이 (나와 같은) 자신의 솔루션을 사용하지만 다른 사람에게 솔루션을 제공할 필요성을 느끼지 못한다고 생각합니다. 그러나 일반적으로 MFC와 같이 잘 알려진 라이브러리를 기반으로 하는 표준이 있으면 더 좋을 것이라고 생각합니다. 이것이 내가 MQ를 이해하지 못하는 이유입니다. 기성 솔루션을 이식하는 대신 자체 휠을 발명해야 하는 이유(매우 논란의 여지가 있음)이기도 합니다. 그러나 MQL 언어 자체에 대해서도 마찬가지입니다.))
하지만 원칙적으로 나는 누군가에게 CObject를 버리라고 강요하지 않았고, MQ에서 멋진 CObject가 있으면 누군가가 CMyCobject를 사용하는 이유를 말하는 문구에 대한 응답으로 비판적 발언을 했습니다. :)
MQL로 문명화된 라이브러리를 작성한 다음 이야기하겠습니다. 이 비명은 몇 년 동안 들렸고, 그것이 나오자 마자 솔직한 바이들로코딩이 시작됩니다.
글쎄, 나는 내 자신의 라이브러리를 가지고 있습니다. 그래서 무엇에 대해 이야기하고 싶었습니까?
CObject MQ의 참조가 정말 엉망입니다. 그들은 거기에 있어서는 안됩니다. 그리고 이러한 링크는 CList와 같은 매우 특정한 컨테이너에서 사용됩니다. 그러나 실수는 어디에 있습니까? 당신은 문명 언어를 구사합니까? 같은 Richter에 대한 비판, 그가 Object C #에 대해 어떻게 생각하는지, 그리고 그의 의견으로는 그 안에 있으면 안 되는 방법을 읽으십시오. 그렇다면 리히터가 옳기 때문에 C# 사용을 중단해야 합니까? 날뛰다. 그러니 여기에서 쌓이는 것을 멈추고 마침내 절차상의 정글로 가십시오.
야망도 덜하고 무례하기도 해서 당신과 사적인 관계를 맺지 못했습니다.
"링크로 망친 것"에 대해 - 글쎄요, 재미있습니다. 이미 그것에 대해 모든 것을 그렸기 때문입니다. 이전에 여기에서 말 그대로 CObject 에 대해 그렸지만 너무 훌륭하고 기본적으로 포인터도 초기화되지 않습니다(최소한 사용자가 코딩하는 언어에 대해 먼저 배울 것입니다). 일반적으로 여기에서 구슬을 던질 이유가 더 이상 없습니다.
George Merts : 그러나 OOP를 사용하는 것이 항상 필요한 것은 아니라는 점에 동의합니다.
CDataProvider:pulic 클래스가 있다고 가정해 보겠습니다. CDataProviderI는 시계열, 표시기, 터미널 및 환경 데이터를 EA에 제공하는 데이터 공급자입니다. Expert Advisor 내부에는 많은 TS가 있을 수 있습니다. 각 TS는 데이터 제공자로부터 시계열 및 표시기에 대한 포인터를 받습니다(결과적으로 각 TS는 이러한 시계열 생성을 처리할 필요가 없습니다. 데이터 제공자는 필요한 시계열, 이미 존재하는 경우 아직 생성되지 않은 시계열만 생성합니다.
데이터 제공자로부터 지표를 받아야 하는 경우 지표 설명 구조를 채운 다음 이 구조를 가리키는 제공자에게 지표를 요청해야 합니다.
따라서 데이터 제공자 내부의 각 표시기는 자체 구조를 인식할 수 있어야 하며(데이터 제공자는 구조의 추상 기본 클래스에만 "익숙함" 있음) 이를 사용하여 기성품 표시기 객체를 생성할 수 있어야 합니다. 데이터 제공자가 발행합니다.
그러나 일종의 지표에 대한 새로운 아이디어를 테스트하기 위해이 전체 정원을 펜싱하는 것은 물론 비합리적입니다. 결과적으로 이러한 새로운 지표의 경우 모든 것이 OOP 없이 "무릎에 조립"됩니다. 그러나 지표가 Expert Advisors에 유용하다는 것을 알면 "예상대로" 작성됩니다. 완전한 OOP 지원 및 데이터 제공자 내부 생성이 포함됩니다.
작업에 동일한 표시기를 사용하는 많은 차량에 대한 훌륭한 솔루션입니다. 그러나 시험에는 적합하지 않으므로 무릎을 꿇고 작성해야 합니다.
약 15년 전에 MT4의 모든 지표를 리버스 포지션 모드에서 거래하기에 적합한지 테스트했을 때 당일 수익을 내는 지표는 1개뿐이었습니다. 대부분의 지표는 내장 지표를 기반으로 구축되어 결과적으로 거의 모든 거래의 효율성이 낮습니다. 예측의 정확성이나 패턴의 수익성을 위해 시장을 연구하는 것은 모든 거래자의 첫 번째 과제라고 생각합니다. 환경 및 기능 설명, 이것은 이익을 주는 이미 발견된 패턴을 작업하는 데 편안함이 필요합니다.
감사합니다.
추신: 그리고 항상 비평가, 멍청이, 트롤링을 좋아하는 사람들이 있을 것입니다. 가장 중요한 것은 그들이 당신이 가고 있는 방향에서 당신을 노크하고 아이디어의 구현을 볼 수 없다는 것입니다. 결국, 이 전체 서커스의 임무는 혼란을 일으키고 이익에서 멀어지는 잘못된 방향으로 지시하는 것입니다.
글쎄, 일반적으로 일반 CObject는 다른 모든 것도 표준 라이브러리 를 기반으로 할 때 사용됩니다.
특히, 자신의 소스코드를 적극적으로 공유하는 사람들은 대개 통일을 위해 노력하고,
자체 작성 코드 감소 및
자체 도서관의 수를 줄이고,
타사 사용자의 삶을 더 쉽게 만들기 위해. 그러나 여기서 모든 사람은 자신을 위해 인코딩할지 아니면 다른 사람의 편의를 위해 인코딩할지 스스로 결정합니다.
글쎄, 당신은 스스로 작성하는 자전거가 아니라 CObject를 사용해야하는 이유에 대한 질문에 스스로 대답했습니다. 이것은 "통일", "자체 작성 코드 감소", "자체 라이브러리 수 감소"라는 단어가 있기 때문에 다른 사람뿐만 아니라 무엇보다도 먼저 자신의 삶을 더 쉽게 만드는 데 필요합니다. 이것이 모든 개발자 노력해야 합니다. 이것은 프로그래머의 성배입니다.
물론 표준 라이브러리는 구식입니다. 이제 언어를 사용하여 제네릭을 만들 수 있으며 이제 인터페이스가 있습니다. 그러나 오래된 것은 효과가 있고 그것은 좋은 통일이며 그들이 말하는 바와 같이 가장 좋은 것은 좋은 것의 적입니다. 왜냐하면 가장 이상적이고 좋은 것은 없습니다. 좋은 것을 사용해야 합니다.
"링크로 망친 것"에 대해 - 글쎄요, 재미있습니다. 이미 그것에 대해 모든 것을 그렸기 때문입니다. 이전에 CObject에서 문자 그대로 "draw ** 여부"를 언급했지만, 매우 훌륭하고 기본적으로 포인터도 초기화되지 않는다고 말했습니다(최소한 코딩하는 언어에 대해 시작하는 하드웨어 chtol을 배워야 합니다. ). 일반적으로 여기에서 구슬을 던질 이유가 더 이상 없습니다.
아무도 여기에서 당신 앞에 엎드려 절하지 않을 것입니다. 저를 믿으십시오. 당신이 여기에서 우리 모두를 위해 "발견"한 "신성한" 지식은 오랫동안 많은 사람들에게 알려져 왔습니다. 나는 링크의 초기화에 대해 논쟁하지도 않을 것이다. 당신은 형식적으로 당신이 옳다는 것을 알고 있습니다. 그래서 당신은 같은 것에 내 코를 찌르려고 하는 것입니다. 그들은 말합니다, 매트 부분을 읽고, NULL이 무엇인지 배우십시오, 등등. 그러나 나는 가르칠 필요가 없습니다. 당신은 멋져요. 당신은 모든 것을 가지고 있습니다. 그런데 왜 우리 앞에 구슬을 던지는 겁니까? 다음으로 이동하는 것이 좋습니다.%:#%; 당신의 도서관에. 그녀는 0.5% 더 빨리 벌 것입니다.
Andrey Kisselyov : 작업에 동일한 표시기를 사용하는 많은 차량에 대한 훌륭한 솔루션입니다. 그러나 시험에는 적합하지 않으므로 무릎을 꿇고 작성해야 합니다.
약 15년 전에 MT4의 모든 지표를 리버스 포지션 모드에서 거래하기에 적합한지 테스트했을 때 당일 수익을 내는 지표는 1개뿐이었습니다. 대부분의 지표는 내장 지표를 기반으로 구축되어 결과적으로 거의 모든 거래의 효율성이 낮습니다. 예측의 정확성이나 패턴의 수익성을 위해 시장을 연구하는 것은 모든 거래자의 첫 번째 과제라고 생각합니다. 환경 및 기능 설명, 이것은 이익을 주는 이미 발견된 패턴을 작업하는 데 편안함이 필요합니다.
아니요, 여기서 지표의 본질에 올바르게 접근하면됩니다. 지표는 기성품 Grail 이 아니라 단순히 가격 움직임의 일부 기능을 편리하게 표현한 것입니다. 따라서 그들에 대한 접근은 전혀 "최종 신호원"이 아니라 일종의 "신호의 신호"로 단순하게 조합하여 사용해야 합니다. 그리고 이 경우 대부분의 테스트에서 많은 지표가 필요하기 시작합니다. 특히 ATR - 거의 모든 곳에서 사용하기 때문에 템플릿에 Expert Advisor를 표준으로 포함하는 것을 이미 생각하고 있습니다. 동일한 Mashki도 종종 필요한 지표입니다. 프랙탈, 핀바 표시기...
CDataProvider:pulic 클래스가 있다고 가정해 보겠습니다. CDataProviderI는 시계열, 표시기, 터미널 및 환경 데이터를 EA에 제공하는 데이터 공급자입니다. Expert Advisor 내부에는 많은 TS가 있을 수 있습니다. 각 TS는 데이터 제공자로부터 시계열 및 표시기에 대한 포인터를 받습니다(결과적으로 각 TS는 이러한 시계열 생성을 처리할 필요가 없습니다. 데이터 제공자는 필요한 시계열, 이미 존재하는 경우 아직 생성되지 않은 시계열만 생성합니다.
데이터 제공자로부터 지표를 받아야 하는 경우 지표 설명 구조를 채운 다음 이 구조를 가리키는 제공자에게 지표를 요청해야 합니다.
따라서 데이터 제공자 내부의 각 표시기는 자체 구조를 인식할 수 있어야 하며(데이터 제공자는 구조의 추상 기본 클래스에만 "익숙함" 있음) 이를 사용하여 기성품 표시기 객체를 생성할 수 있어야 합니다. 데이터 제공자가 발행합니다.
그러나 일종의 지표에 대한 새로운 아이디어를 테스트하기 위해이 전체 정원을 펜싱하는 것은 물론 비합리적입니다. 결과적으로 이러한 새로운 지표의 경우 모든 것이 OOP 없이 "무릎에 조립"됩니다. 그러나 지표가 Expert Advisors에 유용하다는 것을 알면 "예상대로" 작성됩니다. 완전한 OOP 지원 및 데이터 제공자 내부 생성이 포함됩니다.
추신
그런데 지표와 데이터 공급자의 경우 상속 가상화의 이점이 분명히 보입니다. 기본 지표 매개변수 인터페이스 CIndicatorParametersI가 있으며 이 인터페이스의 후속 제품은 필수 지표의 실제 매개변수입니다. 표시기를 요청할 때 이러한 매개변수를 선언하고 추상 인터페이스에 대한 포인터를 데이터 제공자에게 전달합니다. 따라서 데이터 제공자 자체는 어떤 지표가 요청되었는지조차 알지 못합니다. 이는 필요한 유형의 새로운 지표가 생성되는 하나의 기능에서 결정됩니다. 그리고 정확히 어떤 매개변수가 전달되는지 - 이 생성된 표시기만 알고 전달된 객체에서 필요한 매개변수를 추출합니다.
트릭은 데이터 제공자 내부의 거의 모든 곳에서 매개변수(또는 표시기)의 간단한 기본 클래스로 작업이 수행되고 있다는 것입니다. 기본 인터페이스의 가장 단순하고 가장 일반적인 기능만 데이터 제공자가 사용할 수 있습니다. 이것은 코드 수정을 단순화하고(필요한 경우) 데이터 제공자의 표시기 코드에 "들어가는" 유혹을 만들지 않습니다. 지표를 변경해야 하는 경우 지표 자체 내에서만 수행되는 반면 데이터 공급자는 지표의 저장소일 뿐이며 할 수 있는 최대치는 새 지표를 생성하는 것입니다.
당신은 나를 더 어렵게 만들고 있습니다. 데이터 제공자는 MetaTrader 자체입니다. 저것들. 권한 편집기는 필요하지 않으며 데이터 작업을 위한 사용자 친화적인 인터페이스만 있으면 됩니다. 예를 들어, 내 라이브러리에서 작동하는 도구의 마지막 막대를 여는 가격을 얻으려면 다음과 같이 작성하면 됩니다.
double open_price = WS. Open [ 0 ];
WS 개체는 항상 존재하며 항상 가까이에 있고 작동합니다. 그가 하는 방법은 무대 뒤에서 숨겨져 있습니다. 이것이 모든 데이터 액세스입니다 :)
추신 OOP는 시스템 사용의 복잡성을 높이는 것이 아니라 줄여야 합니다. 그리고 간단한 확인을 위해 정원을 울타리로 만들 필요가 있음을 스스로 인정한다면 공급자의 아키텍처에 문제가 있는 것입니다. 저것들. 당신은 당신 자신이 항상 사용하고 싶지 않은 것을 프로그래밍했습니다.
아니요, 여기서 지표의 본질에 올바르게 접근하면됩니다. 지표는 기성품 Grail이 아니라 단순히 가격 움직임의 일부 기능을 편리하게 표현한 것입니다. 따라서 그들에 대한 접근은 전혀 "신호의 궁극적인 소스"가 아니라 일종의 "신호의 신호"로 단순하게 조합하여 사용해야 합니다. 그리고 이 경우 대부분의 테스트에서 많은 지표가 필요하기 시작합니다. 특히 ATR - 거의 모든 곳에서 사용하기 때문에 템플릿에 Expert Advisor를 표준으로 포함하는 것을 이미 생각하고 있습니다. 동일한 Mashki도 종종 필요한 지표입니다. 프랙탈, 핀바 표시기...
나는 ATP를 지표로 생각하지 않고 진입 신호가 적합하지 않기 때문에 특정 기간 동안의 평균 시장 변동성을 보여줍니다(필터로 사용할 수 있음, 더 이상). Masha는 역 위치 모드에서 마이너스 이익을 제공합니다. 프랙탈도. 핀바 표시기는 내장되어 있지 않습니다.
나는 반전 표시기의 신호에 대해 "시장에서 항상" 모드로 일하는 것에 대해 이야기하고 있었고 15년 전에 반복하지만 지금은 시장에 대한 나의 비전이 다소 바뀌었습니다.
당신은 나를 더 어렵게 만들고 있습니다. 데이터 제공자는 MetaTrader 자체입니다. 저것들. 권한 편집기는 필요하지 않으며 데이터 작업을 위한 사용자 친화적인 인터페이스만 있으면 됩니다. 예를 들어, 내 라이브러리에서 작동하는 도구의 마지막 막대를 여는 가격을 얻으려면 다음과 같이 작성하면 됩니다.
WS 개체는 항상 존재하며 항상 가까이에 있고 작동합니다. 그가 하는 방법은 무대 뒤에서 숨겨져 있습니다. 이것이 모든 데이터 액세스입니다 :)
추신 OOP는 시스템 사용의 복잡성을 높이는 것이 아니라 줄여야 합니다. 그리고 간단한 확인을 위해 정원을 울타리로 만들 필요가 있음을 스스로 인정한다면 공급자의 아키텍처에 문제가 있는 것입니다. 저것들. 당신은 당신 자신이 항상 사용하고 싶지 않은 것을 프로그래밍했습니다.
귀하의("당신"이라고 합시다) 항목 "WS. Open [ 0 ];" 내 "m_tcMainContainer.Open(0)" 항목과 거의 다릅니다.
WS 개체의 초기화에는 몇 가지 예비 단계가 있어야 한다고 생각합니다.
제 경우에는 bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer) 함수를 호출해야 합니다 .
Expert Advisor의 각 부분(진입 생성기, 후행 및 종료 컨트롤러에서 - 즉, 거래 작업을 수행할 수 있는 객체에서)에는 "Timeseries Container" 객체가 있습니다. 서비스 능력.
Expert Advisor에는 서로 다른 기호와 시간대가 포함된 다양한 컨테이너가 있을 수 있습니다. 데이터 제공자의 이념은 당신이 그것들을 복제할 수 없도록 허용합니다. 실제이기 때문에 모든 시계열이 여기에 저장되고 컨테이너는 단순히 필요한 시계열을 가리킵니다.
큰 차이는 없습니다. 제가 이해하기로는 WS(WareStore, 아마도?)가 여전히 제 데이터 제공업체입니다. 지표, 기호(CSymbolInfo 개체), 터미널(CTerminalInfo 개체)과 같은 다른 데이터도 내 데이터 공급자에 집중되어 있으며 차트 컬렉션도 있습니다. 각 새로 고침 시계열은 필요에 따라 업데이트됩니다. 여기에서 이데올로기는 표준 라이브러리의 이데올로기에 가깝습니다.
MT4-5 자체를 데이터 공급자로 간주하고 액세스를 제공하기 위해서만 클래스를 사용하는 경우 Open 가격에 대한 귀하의 호소에 따라 하나의 값에 대해 CopyOpen() 함수를 호출해야 합니다. 나에게 불합리한.
또한 프로그램의 모든 변수에 대한 전체 전역 액세스 권한을 부여하는 것은 매우 비합리적이라고 생각합니다. 반대로 프로그램의 모든 위치에서 이 작업에 필요한 구조와 데이터에만 액세스할 수 있도록 노력합니다. 다른 모든 것은 사용할 수 없어야 합니다. 데이터 제공자의 이념은 이 액세스를 제어할 수 있도록 허용합니다.
Andrey Kisselyov : 나는 ATP를 지표로 생각하지 않고 진입 신호가 적합하지 않기 때문에 특정 기간 동안의 평균 시장 변동성을 보여줍니다(필터로 사용할 수 있음, 더 이상). Masha는 역 위치 모드에서 마이너스 이익을 제공합니다. 프랙탈도. 핀바 표시기는 내장되어 있지 않습니다.
나는 반전 표시기의 신호에 대해 "시장에서 항상" 모드로 일하는 것에 대해 이야기하고 있었고 15년 전에 반복하지만 지금은 시장에 대한 나의 비전이 다소 바뀌었습니다.
감사합니다.
즉, "ATR이 지표로 간주되지 않는다"는 것은 무엇입니까 ???
그리고 어떻게 "진입 신호로 좋지 않은가요 ??? 그리고 나는 바보입니다, 나는이 지표 만 사용하여 "변동성 분석"엔트리를 사용합니다 ...
지표의 본질에 대한 자신만의 특별한 이해가 있으실 거라 생각합니다... 저에게 지표는 시간에 따라 가변적인 가치를 만들어낼 수 있는 객체입니다. 사실 일반 촛대 가격 차트도 지표입니다. 그러나 당신에게 그것은 다른 것입니다. 따라서 우리의 이해는 다릅니다.
문명화된 세계에서 목록은 다음을 통해 구현됩니다.
MQL로 문명화된 라이브러리를 작성한 다음 이야기하겠습니다. 이 비명은 몇 년 동안 들렸고, 그것이 나오자 마자 솔직한 바이들로코딩이 시작됩니다.
CObject MQ의 참조가 정말 엉망입니다. 그들은 거기에 있어서는 안됩니다. 그리고 이러한 링크는 CList와 같은 매우 특정한 컨테이너에서 사용됩니다. 그러나 어디에 실수가 있습니까? 당신은 문명 언어를 구사합니까? 같은 Richter에 대한 비판, 그가 Object C #에 대해 어떻게 생각하는지, 그리고 그의 의견으로는 그 안에 있으면 안 되는 방법을 읽으십시오. 리히터가 옳기 때문에 C# 사용을 중단해야 합니까? 날뛰다. 그러니 여기에서 쌓이는 것을 멈추고 마침내 절차상의 정글로 가십시오.
네, 상수 객체를 목록에 넣을 수 없습니다.
그러나 동시에 CObject의 기능을 지속적으로 사용하고 비평가 중 누구도 표준 라이브러리의 개체, 배열 및 목록과 유사한 것을 제공하지 않았습니다.
"How to do it"은 모든 사람이 고함치는 방식입니다. 그러나 무언가를 제공하기 위해 - 갑자기 아무것도 없습니다.
실제로 다양한 소프트웨어 솔루션을 제공하는 참가자(CObject'y의 대체품을 제공하지 않음)조차도 "한 곳을 통한 구현"에 주의를 기울이지 않고 더 자주 사용하지 않고 기능을 덜 사용합니다. 따라서 구현 자체에 매우 적합합니다.
그것이 나빴다면 그들은 오래 전에 교체를 제안했을 것입니다.
글쎄, 일반적으로 일반 CObject는 다른 모든 것도 표준 라이브러리 를 기반으로 할 때 사용됩니다. 특히, 자신의 소스 코드를 적극적으로 공유하는 사람들은 일반적으로 타사 사용자의 삶을 더 쉽게 만들기 위해 통합하고 자체 작성 코드를 줄이고 자체 라이브러리 수를 줄이는 경향이 있습니다. 그러나 여기서 모든 사람은 자신을 위해 인코딩할지 아니면 다른 사람의 편의를 위해 인코딩할지 스스로 결정합니다.
그래서 많은 사람들이 (나와 같은) 자신의 솔루션을 사용하지만 다른 사람에게 솔루션을 제공할 필요성을 느끼지 못한다고 생각합니다. 그러나 일반적으로 MFC와 같이 잘 알려진 라이브러리를 기반으로 하는 표준이 있으면 더 좋을 것이라고 생각합니다. 이것이 내가 MQ를 이해하지 못하는 이유입니다. 기성 솔루션을 이식하는 대신 자체 휠을 발명해야 하는 이유(매우 논란의 여지가 있음)이기도 합니다. 그러나 MQL 언어 자체에 대해서도 마찬가지입니다.))
하지만 원칙적으로 나는 누군가에게 CObject를 버리라고 강요하지 않았고, MQ에서 멋진 CObject가 있으면 누군가가 CMyCobject를 사용하는 이유를 말하는 문구에 대한 응답으로 비판적 발언을 했습니다. :)
MQL로 문명화된 라이브러리를 작성한 다음 이야기하겠습니다. 이 비명은 몇 년 동안 들렸고, 그것이 나오자 마자 솔직한 바이들로코딩이 시작됩니다.
글쎄, 나는 내 자신의 라이브러리를 가지고 있습니다. 그래서 무엇에 대해 이야기하고 싶었습니까?
CObject MQ의 참조가 정말 엉망입니다. 그들은 거기에 있어서는 안됩니다. 그리고 이러한 링크는 CList와 같은 매우 특정한 컨테이너에서 사용됩니다. 그러나 실수는 어디에 있습니까? 당신은 문명 언어를 구사합니까? 같은 Richter에 대한 비판, 그가 Object C #에 대해 어떻게 생각하는지, 그리고 그의 의견으로는 그 안에 있으면 안 되는 방법을 읽으십시오. 그렇다면 리히터가 옳기 때문에 C# 사용을 중단해야 합니까? 날뛰다. 그러니 여기에서 쌓이는 것을 멈추고 마침내 절차상의 정글로 가십시오.
야망도 덜하고 무례하기도 해서 당신과 사적인 관계를 맺지 못했습니다.
"링크로 망친 것"에 대해 - 글쎄요, 재미있습니다. 이미 그것에 대해 모든 것을 그렸기 때문입니다. 이전에 여기에서 말 그대로 CObject 에 대해 그렸지만 너무 훌륭하고 기본적으로 포인터도 초기화되지 않습니다(최소한 사용자가 코딩하는 언어에 대해 먼저 배울 것입니다). 일반적으로 여기에서 구슬을 던질 이유가 더 이상 없습니다.
그러나 OOP를 사용하는 것이 항상 필요한 것은 아니라는 점에 동의합니다.
CDataProvider:pulic 클래스가 있다고 가정해 보겠습니다. CDataProviderI는 시계열, 표시기, 터미널 및 환경 데이터를 EA에 제공하는 데이터 공급자입니다. Expert Advisor 내부에는 많은 TS가 있을 수 있습니다. 각 TS는 데이터 제공자로부터 시계열 및 표시기에 대한 포인터를 받습니다(결과적으로 각 TS는 이러한 시계열 생성을 처리할 필요가 없습니다. 데이터 제공자는 필요한 시계열, 이미 존재하는 경우 아직 생성되지 않은 시계열만 생성합니다.
데이터 제공자로부터 지표를 받아야 하는 경우 지표 설명 구조를 채운 다음 이 구조를 가리키는 제공자에게 지표를 요청해야 합니다.
따라서 데이터 제공자 내부의 각 표시기는 자체 구조를 인식할 수 있어야 하며(데이터 제공자는 구조의 추상 기본 클래스에만 "익숙함" 있음) 이를 사용하여 기성품 표시기 객체를 생성할 수 있어야 합니다. 데이터 제공자가 발행합니다.
그러나 일종의 지표에 대한 새로운 아이디어를 테스트하기 위해이 전체 정원을 펜싱하는 것은 물론 비합리적입니다. 결과적으로 이러한 새로운 지표의 경우 모든 것이 OOP 없이 "무릎에 조립"됩니다. 그러나 지표가 Expert Advisors에 유용하다는 것을 알면 "예상대로" 작성됩니다. 완전한 OOP 지원 및 데이터 제공자 내부 생성이 포함됩니다.
약 15년 전에 MT4의 모든 지표를 리버스 포지션 모드에서 거래하기에 적합한지 테스트했을 때 당일 수익을 내는 지표는 1개뿐이었습니다. 대부분의 지표는 내장 지표를 기반으로 구축되어 결과적으로 거의 모든 거래의 효율성이 낮습니다. 예측의 정확성이나 패턴의 수익성을 위해 시장을 연구하는 것은 모든 거래자의 첫 번째 과제라고 생각합니다. 환경 및 기능 설명, 이것은 이익을 주는 이미 발견된 패턴을 작업하는 데 편안함이 필요합니다.
감사합니다.
추신: 그리고 항상 비평가, 멍청이, 트롤링을 좋아하는 사람들이 있을 것입니다. 가장 중요한 것은 그들이 당신이 가고 있는 방향에서 당신을 노크하고 아이디어의 구현을 볼 수 없다는 것입니다. 결국, 이 전체 서커스의 임무는 혼란을 일으키고 이익에서 멀어지는 잘못된 방향으로 지시하는 것입니다.
글쎄, 당신은 스스로 작성하는 자전거가 아니라 CObject를 사용해야하는 이유에 대한 질문에 스스로 대답했습니다. 이것은 "통일", "자체 작성 코드 감소", "자체 라이브러리 수 감소"라는 단어가 있기 때문에 다른 사람뿐만 아니라 무엇보다도 먼저 자신의 삶을 더 쉽게 만드는 데 필요합니다. 이것이 모든 개발자 노력해야 합니다. 이것은 프로그래머의 성배입니다.
물론 표준 라이브러리는 구식입니다. 이제 언어를 사용하여 제네릭을 만들 수 있으며 이제 인터페이스가 있습니다. 그러나 오래된 것은 효과가 있고 그것은 좋은 통일이며 그들이 말하는 바와 같이 가장 좋은 것은 좋은 것의 적입니다. 왜냐하면 가장 이상적이고 좋은 것은 없습니다. 좋은 것을 사용해야 합니다.
"링크로 망친 것"에 대해 - 글쎄요, 재미있습니다. 이미 그것에 대해 모든 것을 그렸기 때문입니다. 이전에 CObject에서 문자 그대로 "draw ** 여부"를 언급했지만, 매우 훌륭하고 기본적으로 포인터도 초기화되지 않는다고 말했습니다(최소한 코딩하는 언어에 대해 시작하는 하드웨어 chtol을 배워야 합니다. ). 일반적으로 여기에서 구슬을 던질 이유가 더 이상 없습니다.
아무도 여기에서 당신 앞에 엎드려 절하지 않을 것입니다. 저를 믿으십시오. 당신이 여기에서 우리 모두를 위해 "발견"한 "신성한" 지식은 오랫동안 많은 사람들에게 알려져 왔습니다. 나는 링크의 초기화에 대해 논쟁하지도 않을 것이다. 당신은 형식적으로 당신이 옳다는 것을 알고 있습니다. 그래서 당신은 같은 것에 내 코를 찌르려고 하는 것입니다. 그들은 말합니다, 매트 부분을 읽고, NULL이 무엇인지 배우십시오, 등등. 그러나 나는 가르칠 필요가 없습니다. 당신은 멋져요. 당신은 모든 것을 가지고 있습니다. 그런데 왜 우리 앞에 구슬을 던지는 겁니까? 다음으로 이동하는 것이 좋습니다.%:#%; 당신의 도서관에. 그녀는 0.5% 더 빨리 벌 것입니다.
작업에 동일한 표시기를 사용하는 많은 차량에 대한 훌륭한 솔루션입니다. 그러나 시험에는 적합하지 않으므로 무릎을 꿇고 작성해야 합니다.
약 15년 전에 MT4의 모든 지표를 리버스 포지션 모드에서 거래하기에 적합한지 테스트했을 때 당일 수익을 내는 지표는 1개뿐이었습니다. 대부분의 지표는 내장 지표를 기반으로 구축되어 결과적으로 거의 모든 거래의 효율성이 낮습니다. 예측의 정확성이나 패턴의 수익성을 위해 시장을 연구하는 것은 모든 거래자의 첫 번째 과제라고 생각합니다. 환경 및 기능 설명, 이것은 이익을 주는 이미 발견된 패턴을 작업하는 데 편안함이 필요합니다.
아니요, 여기서 지표의 본질에 올바르게 접근하면됩니다. 지표는 기성품 Grail 이 아니라 단순히 가격 움직임의 일부 기능을 편리하게 표현한 것입니다. 따라서 그들에 대한 접근은 전혀 "최종 신호원"이 아니라 일종의 "신호의 신호"로 단순하게 조합하여 사용해야 합니다. 그리고 이 경우 대부분의 테스트에서 많은 지표가 필요하기 시작합니다. 특히 ATR - 거의 모든 곳에서 사용하기 때문에 템플릿에 Expert Advisor를 표준으로 포함하는 것을 이미 생각하고 있습니다. 동일한 Mashki도 종종 필요한 지표입니다. 프랙탈, 핀바 표시기...
...
그러나 OOP를 사용하는 것이 항상 필요한 것은 아니라는 점에 동의합니다.
CDataProvider:pulic 클래스가 있다고 가정해 보겠습니다. CDataProviderI는 시계열, 표시기, 터미널 및 환경 데이터를 EA에 제공하는 데이터 공급자입니다. Expert Advisor 내부에는 많은 TS가 있을 수 있습니다. 각 TS는 데이터 제공자로부터 시계열 및 표시기에 대한 포인터를 받습니다(결과적으로 각 TS는 이러한 시계열 생성을 처리할 필요가 없습니다. 데이터 제공자는 필요한 시계열, 이미 존재하는 경우 아직 생성되지 않은 시계열만 생성합니다.
데이터 제공자로부터 지표를 받아야 하는 경우 지표 설명 구조를 채운 다음 이 구조를 가리키는 제공자에게 지표를 요청해야 합니다.
따라서 데이터 제공자 내부의 각 표시기는 자체 구조를 인식할 수 있어야 하며(데이터 제공자는 구조의 추상 기본 클래스에만 "익숙함" 있음) 이를 사용하여 기성품 표시기 객체를 생성할 수 있어야 합니다. 데이터 제공자가 발행합니다.
그러나 일종의 지표에 대한 새로운 아이디어를 테스트하기 위해이 전체 정원을 펜싱하는 것은 물론 비합리적입니다. 결과적으로 이러한 새로운 지표의 경우 모든 것이 OOP 없이 "무릎에 조립"됩니다. 그러나 지표가 Expert Advisors에 유용하다는 것을 알면 "예상대로" 작성됩니다. 완전한 OOP 지원 및 데이터 제공자 내부 생성이 포함됩니다.
추신
그런데 지표와 데이터 공급자의 경우 상속 가상화의 이점이 분명히 보입니다. 기본 지표 매개변수 인터페이스 CIndicatorParametersI가 있으며 이 인터페이스의 후속 제품은 필수 지표의 실제 매개변수입니다. 표시기를 요청할 때 이러한 매개변수를 선언하고 추상 인터페이스에 대한 포인터를 데이터 제공자에게 전달합니다. 따라서 데이터 제공자 자체는 어떤 지표가 요청되었는지조차 알지 못합니다. 이는 필요한 유형의 새로운 지표가 생성되는 하나의 기능에서 결정됩니다. 그리고 정확히 어떤 매개변수가 전달되는지 - 이 생성된 표시기만 알고 전달된 객체에서 필요한 매개변수를 추출합니다.
트릭은 데이터 제공자 내부의 거의 모든 곳에서 매개변수(또는 표시기)의 간단한 기본 클래스로 작업이 수행되고 있다는 것입니다. 기본 인터페이스의 가장 단순하고 가장 일반적인 기능만 데이터 제공자가 사용할 수 있습니다. 이것은 코드 수정을 단순화하고(필요한 경우) 데이터 제공자의 표시기 코드에 "들어가는" 유혹을 만들지 않습니다. 지표를 변경해야 하는 경우 지표 자체 내에서만 수행되는 반면 데이터 공급자는 지표의 저장소일 뿐이며 할 수 있는 최대치는 새 지표를 생성하는 것입니다.
당신은 나를 더 어렵게 만들고 있습니다. 데이터 제공자는 MetaTrader 자체입니다. 저것들. 권한 편집기는 필요하지 않으며 데이터 작업을 위한 사용자 친화적인 인터페이스만 있으면 됩니다. 예를 들어, 내 라이브러리에서 작동하는 도구의 마지막 막대를 여는 가격을 얻으려면 다음과 같이 작성하면 됩니다.
WS 개체는 항상 존재하며 항상 가까이에 있고 작동합니다. 그가 하는 방법은 무대 뒤에서 숨겨져 있습니다. 이것이 모든 데이터 액세스입니다 :)
추신 OOP는 시스템 사용의 복잡성을 높이는 것이 아니라 줄여야 합니다. 그리고 간단한 확인을 위해 정원을 울타리로 만들 필요가 있음을 스스로 인정한다면 공급자의 아키텍처에 문제가 있는 것입니다. 저것들. 당신은 당신 자신이 항상 사용하고 싶지 않은 것을 프로그래밍했습니다.아니요, 여기서 지표의 본질에 올바르게 접근하면됩니다. 지표는 기성품 Grail이 아니라 단순히 가격 움직임의 일부 기능을 편리하게 표현한 것입니다. 따라서 그들에 대한 접근은 전혀 "신호의 궁극적인 소스"가 아니라 일종의 "신호의 신호"로 단순하게 조합하여 사용해야 합니다. 그리고 이 경우 대부분의 테스트에서 많은 지표가 필요하기 시작합니다. 특히 ATR - 거의 모든 곳에서 사용하기 때문에 템플릿에 Expert Advisor를 표준으로 포함하는 것을 이미 생각하고 있습니다. 동일한 Mashki도 종종 필요한 지표입니다. 프랙탈, 핀바 표시기...
나는 반전 표시기의 신호에 대해 "시장에서 항상" 모드로 일하는 것에 대해 이야기하고 있었고 15년 전에 반복하지만 지금은 시장에 대한 나의 비전이 다소 바뀌었습니다.
감사합니다.
당신은 나를 더 어렵게 만들고 있습니다. 데이터 제공자는 MetaTrader 자체입니다. 저것들. 권한 편집기는 필요하지 않으며 데이터 작업을 위한 사용자 친화적인 인터페이스만 있으면 됩니다. 예를 들어, 내 라이브러리에서 작동하는 도구의 마지막 막대를 여는 가격을 얻으려면 다음과 같이 작성하면 됩니다.
WS 개체는 항상 존재하며 항상 가까이에 있고 작동합니다. 그가 하는 방법은 무대 뒤에서 숨겨져 있습니다. 이것이 모든 데이터 액세스입니다 :)
추신 OOP는 시스템 사용의 복잡성을 높이는 것이 아니라 줄여야 합니다. 그리고 간단한 확인을 위해 정원을 울타리로 만들 필요가 있음을 스스로 인정한다면 공급자의 아키텍처에 문제가 있는 것입니다. 저것들. 당신은 당신 자신이 항상 사용하고 싶지 않은 것을 프로그래밍했습니다.귀하의("당신"이라고 합시다) 항목 "WS. Open [ 0 ];" 내 "m_tcMainContainer.Open(0)" 항목과 거의 다릅니다.
WS 개체의 초기화에는 몇 가지 예비 단계가 있어야 한다고 생각합니다.
제 경우에는 bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer) 함수를 호출해야 합니다 .
Expert Advisor의 각 부분(진입 생성기, 후행 및 종료 컨트롤러에서 - 즉, 거래 작업을 수행할 수 있는 객체에서)에는 "Timeseries Container" 객체가 있습니다. 서비스 능력.
Expert Advisor에는 서로 다른 기호와 시간대가 포함된 다양한 컨테이너가 있을 수 있습니다. 데이터 제공자의 이념은 당신이 그것들을 복제할 수 없도록 허용합니다. 실제이기 때문에 모든 시계열이 여기에 저장되고 컨테이너는 단순히 필요한 시계열을 가리킵니다.
큰 차이는 없습니다. 제가 이해하기로는 WS(WareStore, 아마도?)가 여전히 제 데이터 제공업체입니다. 지표, 기호(CSymbolInfo 개체), 터미널(CTerminalInfo 개체)과 같은 다른 데이터도 내 데이터 공급자에 집중되어 있으며 차트 컬렉션도 있습니다. 각 새로 고침 시계열은 필요에 따라 업데이트됩니다. 여기에서 이데올로기는 표준 라이브러리의 이데올로기에 가깝습니다.
MT4-5 자체를 데이터 공급자로 간주하고 액세스를 제공하기 위해서만 클래스를 사용하는 경우 Open 가격에 대한 귀하의 호소에 따라 하나의 값에 대해 CopyOpen() 함수를 호출해야 합니다. 나에게 불합리한.
또한 프로그램의 모든 변수에 대한 전체 전역 액세스 권한을 부여하는 것은 매우 비합리적이라고 생각합니다. 반대로 프로그램의 모든 위치에서 이 작업에 필요한 구조와 데이터에만 액세스할 수 있도록 노력합니다. 다른 모든 것은 사용할 수 없어야 합니다. 데이터 제공자의 이념은 이 액세스를 제어할 수 있도록 허용합니다.
나는 ATP를 지표로 생각하지 않고 진입 신호가 적합하지 않기 때문에 특정 기간 동안의 평균 시장 변동성을 보여줍니다(필터로 사용할 수 있음, 더 이상). Masha는 역 위치 모드에서 마이너스 이익을 제공합니다. 프랙탈도. 핀바 표시기는 내장되어 있지 않습니다.
나는 반전 표시기의 신호에 대해 "시장에서 항상" 모드로 일하는 것에 대해 이야기하고 있었고 15년 전에 반복하지만 지금은 시장에 대한 나의 비전이 다소 바뀌었습니다.
감사합니다.
즉, "ATR이 지표로 간주되지 않는다"는 것은 무엇입니까 ???
그리고 어떻게 "진입 신호로 좋지 않은가요 ??? 그리고 나는 바보입니다, 나는이 지표 만 사용하여 "변동성 분석"엔트리를 사용합니다 ...
지표의 본질에 대한 자신만의 특별한 이해가 있으실 거라 생각합니다... 저에게 지표는 시간에 따라 가변적인 가치를 만들어낼 수 있는 객체입니다. 사실 일반 촛대 가격 차트도 지표입니다. 그러나 당신에게 그것은 다른 것입니다. 따라서 우리의 이해는 다릅니다.