그게 바로 내가 하는 일이다. 그리고 (서버의 실제 히스토리 대신) 어드바이저에게 커스텀 히스토리를 보낼 수 있는 클래스는 이미 저를 위해 작성되었습니다. 그러나 아이디어의 완전한 구현을 위해 고문은 터미널 기능을 직접 사용해서는 안됩니다. 같은 OrderSend()를 가정해 봅시다. 표준 라이브러리가 완벽하게 맞는 역할을 하는 일종의 "래퍼"를 통해서만 작동해야 합니다. 파생 클래스를 작성하여 Expert Advisor에 넣고 - 짜잔 - 이제 과거 데이터에서 작동합니다. 어드바이저가 단말 기능을 직접 사용한다면, 그것에 대해 이야기를 할 수 없습니다.
글쎄, 분명히 내가 매우 만족하고 많은 유사점을 찾은 MFC 라이브러리에 대한 오랜 작업이 영향을 미치고 있습니다. 표준 라이브러리의 개발자들도 MFC에 대해 잘 알고 있다고 확신합니다.
표준 라이브러리의 주요 장점은 OOP 이데올로기에 대한 좋은 지원으로, 필요한 경우 사용자 지정 기록을 어드바이저에게 전송하여 어드바이저가 변경 없이 아주 정상적으로 작동하도록 할 수 있습니다.
그리고 표준 라이브러리가 마음에 들지 않는 것을 물어볼 수 있습니다("배우기에는 너무 게으름"이라는 명백한 빼기 제외)?
그런 마이너스는 없습니다. 저는 안전보장이사회를 완벽하게 알고 있습니다. 이 지식은 모든 것이 얼마나 번거롭고 비효율적인지 이해하게 해줍니다.
주문을 보내는 대신 할머니는 할아버지를, 할아버지는 순무를 시작합니다.
그러나 (Trade에 의한) 주요 단점은 실행 제어가 완전히 없다는 것입니다. 서버에 주문을 밀어넣고 최소한 풀은 자라지 않습니다. 그러나 그들은 모든 경우와 같이 10가지 방법으로 Send를 포장했고 100개의 케이스가 있었습니다.
이념적으로: 2대 이상 상속을 잘못 생각하면 이해와 유연성이 모두 상실됩니다.
대부분의 클래스(당신 말이 맞아)는 발명되지 않았지만 MFC로 어리석게 중단되었습니다. 음, 이것은 마이너스가 아닐 가능성이 더 큽니다. 왜 바퀴를 재발명합니까?
하지만 가장 큰 단점은 거기에 의지할 수 없다는 점, 무엇인가 쓰다보면 마무리가 되는 것 같아요 :)
나는 SB의 유무에 관계없이 썼다. 그것이 없으면 더 빠르고 투명해집니다. 너무 다재다능해서 커브에 서툴다.
예를 들어 델파이에는 공동 컴파일을 의미 하는 프로젝트 개념이 있습니다. 그리고 프로그램을 3가지 유형으로 나누는 것은 일반적으로 약간 의심스럽습니다. 왜냐하면 이론적으로 컴파일러 자체가 프로그램이 수행하는 작업을 결정할 수 있기 때문입니다. 코드가 내부에 있으면 개발자의 마음이 언젠가 녹아서 프로젝트를 만들 수 있기를 바랄 뿐입니다.)
그런 마이너스는 없습니다. 저는 안전보장이사회를 완벽하게 알고 있습니다. 이 지식은 모든 것이 얼마나 번거롭고 비효율적인지 이해하게 해줍니다.
자세한 답변 감사합니다. 나는 당신의 모든 진술에 대해 단호한 반대가 없습니다. 그래서.. 몇가지 참고사항...
주문을 보내는 대신 할머니는 할아버지를, 할아버지는 순무를 시작합니다.
그러나 이것이 바로 시스템 유연성을 제공하는 것이며, 바로 이 때문에 맞춤형 기록 및 서버 에뮬레이션을 어드바이저에게 전송할 수 있습니다. OrderSend() 를 통해 직접 주문을 보낸 경우 - "할아버지는 할머니, 순무는 할아버지"를 직접 작성해야 합니다. 어느 것이 더 나은지 확실하지 않습니다...
그러나 (Trade에 의한) 주요 단점은 실행 제어가 완전히 없다는 것입니다. 서버에 주문을 밀어넣고 최소한 풀은 자라지 않습니다. 그러나 그들은 모든 경우와 같이 10가지 방법으로 Send를 래핑했으며 100개의 케이스가 있었습니다.
나는 여기에 충분한 경험이 없습니다. 지금은 이론화만 할 수 있습니다. 반환 코드 분석 - 여전히 직접 하고 있지만 업무 경험이 거의 없습니다. 나는 안전보장이사회 자체의 집행 통제만으로는 충분하지 않다는 데 동의합니다.
이념적으로: 2대 이상 상속을 잘못 생각하면 이해와 유연성이 모두 상실됩니다.
그렇습니다. 너무 깊은 상속은 이해력에 매우 좋지 않은 영향을 미칩니다. 그러나 유연성에 대해서는 동의하기 어렵습니다. 4~5대에 상속의 경우가 많은데 별 문제 없을 것 같습니다. 그러나 나는 이것이 나에게나 다른 사람들에게나 마찬가지라는 데 동의할 수 있습니다. 아마도 그러한 유산의 깊이가 크게 방해가 될 것입니다.
하지만 가장 큰 단점은 거기에 의지할 수 없다는 점, 무엇인가 쓰다보면 마무리가 되는 것 같아요 :)
여기 - 예, 전적으로 동의합니다.
나는 SB를 사용하거나 사용하지 않고 썼습니다. 그것이 없으면 더 빠르고 투명해집니다. 너무 다재다능해서 커브에 서툴다.
나는 TS 템플릿을 생성할 수 있는 가능성과 미래에 입력, 반주 및 출력을 설명하는 개체 클래스만 연결할 수 있다는 점에서 SB를 좋아했습니다. 저는 안전보장이사회가 없다면 그러한 이념이 동일한 안전보장이사회를 만들게 될까봐 두렵습니다.
"더 빠르고 투명한"에 관해서는 - 우리가 모든 차량을 전체적으로 고려할 때 그러한 이데올로기가 좋은 것 같습니다. 그러나 이것은 알고리즘 거래에서 심각한 실수라고 생각합니다. TS는 입력 생성기 세트, 입력 TP-SL 결정기, 입력 로트 결정기, 후행 컨트롤러 등 "큐브"의 복합체로 독점적으로 간주되어야 합니다. 이러한 이데올로기는 매우 빠르게 "더 빠르고 투명한" TS의 수백 가지 변형을 수신합니다.
템플리트 없이 5개의 다른 TS를 작성했다고 가정해 보겠습니다. 여섯 번째를 작성하려면 이 5개 시스템의 조각을 사용하더라도 모든 것을 다시 작성해야 합니다. 템플릿을 작성한 후에는 이 5가지 시스템을 부분적으로만 망치질하여 최대 5개의 입력 생성기, 입력 필터, TP-SL 결정자 등을 갖게 됩니다. 그것들을 결합하면 수백 대의 차량을 쉽게 얻을 수 있으며 그 중에서 가장 안정적이고 수익성있는 차량을 선택할 수 있습니다.
따라서 제 생각에는 안보리의 부진은 그야말로 '양날의 검'이며, 그 사용 여부는 사안별로 개별적으로 결정되어야 한다고 생각합니다.
우리가 시장을 접한 이래로 한 가지 문제에 대한 의견을 듣고 싶습니다 ...
MQL5의 철학에 따르면 지표는 계산되어야 하고 Expert Advisors는 거래되어야 합니다.
그러나 시장은 기성품 솔루션을 모두 하나로 판매합니다.
지표가 Expert Advisors에 리소스로 저장되도록 컴파일러를 수정할 수 있습니까?
그렇지 않으면 표시기 코드를 적절한 환경이 없는 Expert Advisor로 전송해야 합니다. 다시 말하지만, "지표에서 표시기" 체계를 사용하면 코드를 Expert Advisor로 전송하는 것이 이미 완전한 무용담입니다.
나는 지원한다
예를 들어 세트, 지침 등을 넣을 수 있는 또 다른 탭인 FILES를 추가하는 것이 시장에서 유용할 것이라고 생각합니다.
하지만 - 토론 탭은 그러한 기회를 제공하지만 여전히 그렇지는 않습니다.
지표가 Expert Advisors에 리소스로 저장되도록 컴파일러를 수정할 수 있습니까?
그렇지 않으면 표시기 코드를 적절한 환경이 없는 Expert Advisor로 전송해야 합니다. 다시 말하지만, "지표에서 표시기" 체계를 사용하면 코드를 Expert Advisor로 전송하는 것이 이미 완전한 무용담입니다.
2012년 11월 24일 뉴스 MetaTrader 5 클라이언트 터미널 빌드 730 보기
8. MQL5: EX5 리소스에 표시기를 저장하기 위한 지원이 추가되었습니다. 동시에 리소스의 지표는 자체 리소스와 함께 작동하지 않습니다.
2012년 11월 24일 MetaTrader 5 클라이언트 터미널 빌드 730 뉴스 보기
그게 바로 내가 하는 일이다. 그리고 (서버의 실제 히스토리 대신) 어드바이저에게 커스텀 히스토리를 보낼 수 있는 클래스는 이미 저를 위해 작성되었습니다. 그러나 아이디어의 완전한 구현을 위해 고문은 터미널 기능을 직접 사용해서는 안됩니다. 같은 OrderSend()를 가정해 봅시다. 표준 라이브러리가 완벽하게 맞는 역할을 하는 일종의 "래퍼"를 통해서만 작동해야 합니다. 파생 클래스를 작성하여 Expert Advisor에 넣고 - 짜잔 - 이제 과거 데이터에서 작동합니다. 어드바이저가 단말 기능을 직접 사용한다면, 그것에 대해 이야기를 할 수 없습니다.
글쎄, 분명히 내가 매우 만족하고 많은 유사점을 찾은 MFC 라이브러리에 대한 오랜 작업이 영향을 미치고 있습니다. 표준 라이브러리의 개발자들도 MFC에 대해 잘 알고 있다고 확신합니다.
표준 라이브러리의 주요 장점은 OOP 이데올로기에 대한 좋은 지원으로, 필요한 경우 사용자 지정 기록을 어드바이저에게 전송하여 어드바이저가 변경 없이 아주 정상적으로 작동하도록 할 수 있습니다.
그리고 표준 라이브러리가 마음에 들지 않는 것을 물어볼 수 있습니다("배우기에는 너무 게으름"이라는 명백한 빼기 제외)?
그런 마이너스는 없습니다. 저는 안전보장이사회를 완벽하게 알고 있습니다. 이 지식은 모든 것이 얼마나 번거롭고 비효율적인지 이해하게 해줍니다.
주문을 보내는 대신 할머니는 할아버지를, 할아버지는 순무를 시작합니다.
그러나 (Trade에 의한) 주요 단점은 실행 제어가 완전히 없다는 것입니다. 서버에 주문을 밀어넣고 최소한 풀은 자라지 않습니다. 그러나 그들은 모든 경우와 같이 10가지 방법으로 Send를 포장했고 100개의 케이스가 있었습니다.
이념적으로: 2대 이상 상속을 잘못 생각하면 이해와 유연성이 모두 상실됩니다.
대부분의 클래스(당신 말이 맞아)는 발명되지 않았지만 MFC로 어리석게 중단되었습니다. 음, 이것은 마이너스가 아닐 가능성이 더 큽니다. 왜 바퀴를 재발명합니까?
하지만 가장 큰 단점은 거기에 의지할 수 없다는 점, 무엇인가 쓰다보면 마무리가 되는 것 같아요 :)
나는 SB의 유무에 관계없이 썼다. 그것이 없으면 더 빠르고 투명해집니다. 너무 다재다능해서 커브에 서툴다.
예를 들어 델파이에는 공동 컴파일을 의미 하는 프로젝트 개념이 있습니다. 그리고 프로그램을 3가지 유형으로 나누는 것은 일반적으로 약간 의심스럽습니다. 왜냐하면 이론적으로 컴파일러 자체가 프로그램이 수행하는 작업을 결정할 수 있기 때문입니다. 코드가 내부에 있으면 개발자의 마음이 언젠가 녹아서 프로젝트를 만들 수 있기를 바랄 뿐입니다.)
나는 지원한다
예를 들어 세트, 지침 등을 넣을 수 있는 또 다른 탭인 FILES를 추가하는 것이 시장에서 유용할 것이라고 생각합니다.
하지만 - 토론 탭은 그러한 기회를 제공하지만 여전히 그렇지는 않습니다.
2012년 11월 24일 뉴스 MetaTrader 5 클라이언트 터미널 빌드 730 보기
좋아, 내가 이것을 어떻게 놓쳤는지, 아, 새해 빌드입니다.
게시물의 취소선이 이미 가능하다는 것을 의미합니까?
그런 마이너스는 없습니다. 저는 안전보장이사회를 완벽하게 알고 있습니다. 이 지식은 모든 것이 얼마나 번거롭고 비효율적인지 이해하게 해줍니다.
자세한 답변 감사합니다. 나는 당신의 모든 진술에 대해 단호한 반대가 없습니다. 그래서.. 몇가지 참고사항...
주문을 보내는 대신 할머니는 할아버지를, 할아버지는 순무를 시작합니다.
그러나 이것이 바로 시스템 유연성을 제공하는 것이며, 바로 이 때문에 맞춤형 기록 및 서버 에뮬레이션을 어드바이저에게 전송할 수 있습니다. OrderSend() 를 통해 직접 주문을 보낸 경우 - "할아버지는 할머니, 순무는 할아버지"를 직접 작성해야 합니다. 어느 것이 더 나은지 확실하지 않습니다...
그러나 (Trade에 의한) 주요 단점은 실행 제어가 완전히 없다는 것입니다. 서버에 주문을 밀어넣고 최소한 풀은 자라지 않습니다. 그러나 그들은 모든 경우와 같이 10가지 방법으로 Send를 래핑했으며 100개의 케이스가 있었습니다.
나는 여기에 충분한 경험이 없습니다. 지금은 이론화만 할 수 있습니다. 반환 코드 분석 - 여전히 직접 하고 있지만 업무 경험이 거의 없습니다. 나는 안전보장이사회 자체의 집행 통제만으로는 충분하지 않다는 데 동의합니다.
이념적으로: 2대 이상 상속을 잘못 생각하면 이해와 유연성이 모두 상실됩니다.
그렇습니다. 너무 깊은 상속은 이해력에 매우 좋지 않은 영향을 미칩니다. 그러나 유연성에 대해서는 동의하기 어렵습니다. 4~5대에 상속의 경우가 많은데 별 문제 없을 것 같습니다. 그러나 나는 이것이 나에게나 다른 사람들에게나 마찬가지라는 데 동의할 수 있습니다. 아마도 그러한 유산의 깊이가 크게 방해가 될 것입니다.
하지만 가장 큰 단점은 거기에 의지할 수 없다는 점, 무엇인가 쓰다보면 마무리가 되는 것 같아요 :)
여기 - 예, 전적으로 동의합니다.
나는 SB를 사용하거나 사용하지 않고 썼습니다. 그것이 없으면 더 빠르고 투명해집니다. 너무 다재다능해서 커브에 서툴다.
나는 TS 템플릿을 생성할 수 있는 가능성과 미래에 입력, 반주 및 출력을 설명하는 개체 클래스만 연결할 수 있다는 점에서 SB를 좋아했습니다. 저는 안전보장이사회가 없다면 그러한 이념이 동일한 안전보장이사회를 만들게 될까봐 두렵습니다.
"더 빠르고 투명한"에 관해서는 - 우리가 모든 차량을 전체적으로 고려할 때 그러한 이데올로기가 좋은 것 같습니다. 그러나 이것은 알고리즘 거래에서 심각한 실수라고 생각합니다. TS는 입력 생성기 세트, 입력 TP-SL 결정기, 입력 로트 결정기, 후행 컨트롤러 등 "큐브"의 복합체로 독점적으로 간주되어야 합니다. 이러한 이데올로기는 매우 빠르게 "더 빠르고 투명한" TS의 수백 가지 변형을 수신합니다.
템플리트 없이 5개의 다른 TS를 작성했다고 가정해 보겠습니다. 여섯 번째를 작성하려면 이 5개 시스템의 조각을 사용하더라도 모든 것을 다시 작성해야 합니다. 템플릿을 작성한 후에는 이 5가지 시스템을 부분적으로만 망치질하여 최대 5개의 입력 생성기, 입력 필터, TP-SL 결정자 등을 갖게 됩니다. 그것들을 결합하면 수백 대의 차량을 쉽게 얻을 수 있으며 그 중에서 가장 안정적이고 수익성있는 차량을 선택할 수 있습니다.
따라서 제 생각에는 안보리의 부진은 그야말로 '양날의 검'이며, 그 사용 여부는 사안별로 개별적으로 결정되어야 한다고 생각합니다.
좋아, 내가 이것을 어떻게 놓쳤는지, 아, 새해 빌드입니다.
게시물의 취소선이 이미 가능하다는 것을 의미합니까?
좋아, 내가 이것을 어떻게 놓쳤는지, 아, 새해 빌드입니다.
여기에서 논의되었습니다: https://www.mql5.com/en/forum/3409#comment_408123