모든 것이 올바르게 말해지고 있습니다. 저는 부드러운 기능을 작성한 다음 실제로 "난독화"하여 사랑스럽고 이해할 수 없게 만들었습니다. 강제적인 결정이었다. 이 경우 전체 수업의 가시성이 나에게 더 중요했습니다. 하나의 아주 사소한 기능의 가시성 - 나는 희생했습니다. 물론 이 함수의 본문을 .mq5 파일로 옮기는 것도 가능하지만 인터페이스를 두 개의 파일로 분할해서는 안 되며 .mqh 헤더 파일에 완전히 설명해야 한다고 생각합니다.
속도도 염두에 둬야 할 부분이지만, '어떤 대가를 치르더라도 속도'를 목표로 해서는 안 된다고 생각한다. 합리적으로 충분해야 합니다.
가독성을 위해 코드를 최적화할 때 이것은 프로그래머에게 더 큰 문제입니다. 그리고 여기서 다시 한번 무거운 기능이 발생하지 않도록 고속 성능에 대한 최적화가 필요합니다. 최근에 한 명의 Expert Advisor를 Mql4에서 MQL5로 전환했습니다. 여기에 게시된 라이브러리를 사용했습니다. 반나절부터 pokvyryal, 모든 기능을 파악하고 작동했지만 최적화가 매우 느립니다. 나는 표시기를 2개의 막대로 자르고 모든 것이 날아가기 시작했습니다.
결론은 간단합니다. 누구나 어떤 스타일로든 쓸 수 있습니다. MQL은 절차 작성을 사용하여 몇 밀리초를 확보하기 위해 코드 최적화가 필요한 종류의 언어가 아닙니다. 모든 동일한 논리적 작업에 더 많은 관심이 집중됩니다. 그리고 그것들이 실제로 어떻게 구현되는지는 속도에 영향을 미치지 않습니다.
결론은 간단합니다. 누구나 어떤 스타일로든 쓸 수 있습니다. MQL은 절차 작성을 통해 몇 밀리초를 확보하기 위해 코드 최적화가 필요한 언어가 아닙니다 . 모든 동일한 논리적 작업에 더 많은 관심이 집중됩니다. 그리고 그것들이 실제로 어떻게 구현되는지는 속도에 영향을 미치지 않습니다.
눈에 띄지 않게 부드럽게 요약되어 고성능을 제공하는 절차적 프로그래밍입니다. 3일째 불필요한 브레이크 없이 OOP만이 풀 수 있는 문제를 보여주고 있습니다.
OOP를 사용하면 코드의 나머지 부분에서 변수 집합을 보호할 수 있으므로 클래스 내에서 계산을 수행할 때 매개변수를 메서드로 전달하는 것에서 벗어날 수 있으며 이는 성능에 중요한 요소입니다. 절차적 방식으로 수행하더라도 엄청난 수의 전역 변수를 생성해야 하므로 결과적으로 코드의 가독성이 불가능할 정도로 떨어집니다.
눈에 띄지 않게 부드럽게 요약되어 고성능을 제공하는 절차적 프로그래밍입니다. 3일째 불필요한 브레이크 없이 OOP만이 풀 수 있는 문제를 보여주고 있습니다.
OOP를 사용하면 코드의 나머지 부분에서 변수 집합을 보호할 수 있으므로 클래스 내에서 계산을 수행할 때 매개변수를 메서드로 전달하는 것에서 벗어날 수 있으며 이는 성능에 중요한 요소입니다. 절차적 방식으로 수행하더라도 엄청난 수의 전역 변수를 생성해야 하므로 결과적으로 코드의 가독성이 불가능할 정도로 떨어집니다.
절차 스타일의 이득은 EA에 각 틱이 도착할 때마다 코드가 실행되기 때문에 무시할 수 있습니다. 그리고 틱 사이에 수백 또는 수십 밀리초가 있을 수 있습니다. 표시기로 귀찮게하지 마십시오. 나는 나 자신에 대한 지표에서 실질적인 이점을 찾지 못했습니다. 대규모 프로젝트는 OOP로 작성하는 것이 더 편리할 수 있습니다. 나는 무언가를 저장해야 할 경우 구조를 사용하는 것을 선호합니다. 그러면 데이터 액세스가 더 시각적이고 드롭다운 메뉴가 사용하기 매우 편리합니다. 구조가 배열로 대체되면 혼동이 자주 발생합니다. 배열의 수가 늘어납니다.
이전 메시지에서는 무거운 함수를 호출하는 데 중점을 두었습니다. 예를 들어, 모든 틱에서 수행할 필요가 없는 주기의 일부 반복. 그리고 모든 새로운 바에서 할 필요도 없습니다. 여기에서 실제 성능 향상을 최대화할 수 있습니다.
1. 기준이 있습니다. 주요 기준은 작업 속도입니다.
코드의 시각화는 잘못된 기준입니다.
우리는 급하게 어셈블리 언어로 전환합니다 ..... 그러나 빨리 .... 진실은 빠르다는 것입니다. 이것은 전체 프로젝트 의 올바른 구성 또는 개별 기능의 속도입니다.
우리는 급하게 sambler 로 전환합니다 ..... 그러나 빨리 .... 진실은 빠르다는 것입니다. 이것은 전체 프로젝트의 올바른 구성 또는 개별 기능의 속도입니다.
우리는 급하게 어셈블리 언어로 전환합니다 ..... 그러나 빨리 .... 진실은 빠르다는 것입니다. 이것은 전체 프로젝트의 올바른 구성 또는 개별 기능의 속도입니다.
아니요, ***를 통해 계속 코딩하십시오.
글쎄, 나는 동의하지 않는다.
시각적 코드는 유지 관리 및 수정이 훨씬 쉽기 때문에 시각적 코드는 매우 중요합니다.
모든 것이 올바르게 말해지고 있습니다. 저는 부드러운 기능을 작성한 다음 실제로 "난독화"하여 사랑스럽고 이해할 수 없게 만들었습니다. 강제적인 결정이었다. 이 경우 전체 수업의 가시성이 나에게 더 중요했습니다. 하나의 아주 사소한 기능의 가시성 - 나는 희생했습니다. 물론 이 함수의 본문을 .mq5 파일로 옮기는 것도 가능하지만 인터페이스를 두 개의 파일로 분할해서는 안 되며 .mqh 헤더 파일에 완전히 설명해야 한다고 생각합니다.
속도도 염두에 둬야 할 부분이지만, '어떤 대가를 치르더라도 속도'를 목표로 해서는 안 된다고 생각한다. 합리적으로 충분해야 합니다.
아마 당신도 같은 포인트 3
저는 오랫동안 프로그래밍을 해왔습니다. MT3 출시와 함께.
그 이후로 절차적 스타일로 mql4로 작성하는 것이 더 편리합니다. 1001 라인에 대한 EA가 없습니다. 라이브러리에 저장하는 일부 기능 외에.
MQL5 에서는 표준 라이브러리를 사용합니다 . 편리한 것.
가독성을 위해 코드를 최적화할 때 이것은 프로그래머에게 더 큰 문제입니다. 그리고 여기서 다시 한번 무거운 기능이 발생하지 않도록 고속 성능에 대한 최적화가 필요합니다. 최근에 한 명의 Expert Advisor를 Mql4에서 MQL5로 전환했습니다. 여기에 게시된 라이브러리를 사용했습니다. 반나절부터 pokvyryal, 모든 기능을 파악하고 작동했지만 최적화가 매우 느립니다. 나는 표시기를 2개의 막대로 자르고 모든 것이 날아가기 시작했습니다.
결론은 간단합니다. 누구나 어떤 스타일로든 쓸 수 있습니다. MQL은 절차 작성을 사용하여 몇 밀리초를 확보하기 위해 코드 최적화가 필요한 종류의 언어가 아닙니다. 모든 동일한 논리적 작업에 더 많은 관심이 집중됩니다. 그리고 그것들이 실제로 어떻게 구현되는지는 속도에 영향을 미치지 않습니다.
...
결론은 간단합니다. 누구나 어떤 스타일로든 쓸 수 있습니다. MQL은 절차 작성을 통해 몇 밀리초를 확보하기 위해 코드 최적화가 필요한 언어가 아닙니다 . 모든 동일한 논리적 작업에 더 많은 관심이 집중됩니다. 그리고 그것들이 실제로 어떻게 구현되는지는 속도에 영향을 미치지 않습니다.
눈에 띄지 않게 부드럽게 요약되어 고성능을 제공하는 절차적 프로그래밍입니다. 3일째 불필요한 브레이크 없이 OOP만이 풀 수 있는 문제를 보여주고 있습니다.
OOP를 사용하면 코드의 나머지 부분에서 변수 집합을 보호할 수 있으므로 클래스 내에서 계산을 수행할 때 매개변수를 메서드로 전달하는 것에서 벗어날 수 있으며 이는 성능에 중요한 요소입니다. 절차적 방식으로 수행하더라도 엄청난 수의 전역 변수를 생성해야 하므로 결과적으로 코드의 가독성이 불가능할 정도로 떨어집니다.
눈에 띄지 않게 부드럽게 요약되어 고성능을 제공하는 절차적 프로그래밍입니다. 3일째 불필요한 브레이크 없이 OOP만이 풀 수 있는 문제를 보여주고 있습니다.
OOP를 사용하면 코드의 나머지 부분에서 변수 집합을 보호할 수 있으므로 클래스 내에서 계산을 수행할 때 매개변수를 메서드로 전달하는 것에서 벗어날 수 있으며 이는 성능에 중요한 요소입니다. 절차적 방식으로 수행하더라도 엄청난 수의 전역 변수를 생성해야 하므로 결과적으로 코드의 가독성이 불가능할 정도로 떨어집니다.
절차 스타일의 이득은 EA에 각 틱이 도착할 때마다 코드가 실행되기 때문에 무시할 수 있습니다. 그리고 틱 사이에 수백 또는 수십 밀리초가 있을 수 있습니다. 표시기로 귀찮게하지 마십시오. 나는 나 자신에 대한 지표에서 실질적인 이점을 찾지 못했습니다.
대규모 프로젝트는 OOP로 작성하는 것이 더 편리할 수 있습니다. 나는 무언가를 저장해야 할 경우 구조를 사용하는 것을 선호합니다.
그러면 데이터 액세스가 더 시각적이고 드롭다운 메뉴가 사용하기 매우 편리합니다. 구조가 배열로 대체되면 혼동이 자주 발생합니다. 배열의 수가 늘어납니다.
이전 메시지에서는 무거운 함수를 호출하는 데 중점을 두었습니다. 예를 들어, 모든 틱에서 수행할 필요가 없는 주기의 일부 반복. 그리고 모든 새로운 바에서 할 필요도 없습니다.
여기에서 실제 성능 향상을 최대화할 수 있습니다.
응. 재미있는 논쟁: 굴착기 대 삽.
아마도 나무를 심을 필요가 있다면 삽이 더 좋습니다. 구덩이를 파면 아마도 굴삭기가 더 나을 것입니다.
응. 재미있는 논쟁: 굴착기 대 삽.
아마도 나무를 심을 필요가 있다면 삽이 더 좋습니다. 구덩이를 파면 아마도 굴삭기가 더 나을 것입니다.
응. 재미있는 논쟁: 굴착기 대 삽.
아마도 나무를 심을 필요가 있다면 삽이 더 좋습니다. 그리고 구덩이를 파면 아마도 굴삭기가 더 나을 것입니다.