토론의 "흐름"에 또 다른 흥미로운 질문이 있습니다. 플랫폼 제한이 MQL 프로그램 작성 스타일에 어느 정도 영향을 미치나요? 예를 들어 논리적으로 분리된 일부 계산을 별도의 기능으로 분리하면 코드를 작성, 이해/읽기 및 지원하기가 더 쉽습니다. 그러나 각 함수 호출 은(특히 MQL과 같은 인터프리터에서) 실행에 소요되는 추가 시간입니다. 단일 호출은 물론 중요하지 않습니다. 대부분의 경우 루프 내부에 이러한 항목을 작성해야 합니다(for int i=0; i<Bars; i++) 등. 그런 다음 코드의 아름다움(나중에 작성한 내용을 이해할 수 있도록 함수 형태로) 또는 실행 속도(동일한 조각을 복사하여 붙여넣기) 중에서 더 중요한 것이 무엇인지 결정하기 시작합니다. 다음 틱이 도착하기 전에 사이클에 모든 것을 해결할 시간이 있습니까?)
각각의 특정한 경우 - 황금 평균의 선을 긋는 결정 - 자체가 분명하지만 .... 누가 이 문제로 어려움을 겪고 있습니까?
아마 그럴 것이다. 나는 고대 언어 Trubo Pascual이 이상적이라고 생각하곤 했습니다. 기능을 구조화할 가능성이 있습니다. 즉. 함수 내에서 함수 선언 C는 이것을 허용하지 않습니다. 그리고 지금은 비슷한 일을 하려고 합니다. 하지만 실제로는 C 플랫폼에서 말이죠. 물론 이것은 외관상일 뿐입니다.
Раньше я считал идеальным древний язык Трубо Паскуаль. Там есть возможность структурирования функций, т.е. объявление функций в функциях.
그런가요? 개인적으로 한때 C로 프로그래밍 언어를 공부하기 시작했습니다. 이제 저는 C와 C++의 두 가지를 압니다. 그리고 나는 그것이 공부하는 데 전혀 다른 것을 끌어들이지 않는다고 말해야 합니다. 함수 내에서 함수를 선언해야 하는 이유는 무엇입니까? 개인적으로 C, C++에서만 자랐기 때문에 이 기술은 이해할 수 없습니다.
C-4>> : 함수 내에서 함수를 선언하는 이유는 무엇입니까? 개인적으로 C, C++에서만 자랐기 때문에 이 기술은 이해할 수 없습니다.
그리고 지금 이해합니다. 여섯 번째 호출 순서까지 함수가 있는 경우 다른 호출 순서의 모든 기능을 하나의 힙에 혼합하는 것이 항상 편리한 것은 아닙니다. 호출 구조의 일반적인 보기가 손실됩니다. 그리고 Trubo Pascual에서는 키 처리를 수행하는 여러 주요 기능과 모든 작은 하위 기능이 내부에 숨겨져 있어 모든 것이 편리합니다.
그러나 이것은 아마도 습관의 문제일 것입니다. 오랫동안 나는 그것에 대해 아무 것도 쓰지 않았습니다. 그리고 나는 그것을 정말로 후회하지 않습니다.
내 생각에, 수업보다 더 나은 것은 아직 예측되지 않았습니다. 클래스 내에서 private 함수를 선언하고 이에 사용할 public 함수를 선언합니다. 아름답고 강력합니다. 함수와 변수를 상속하고 계층 구조를 생각하십시오. 복잡한 데이터 구조를 생성하여 데이터를 캡슐화합니다. 표준 템플릿 라이브러리의 범용 알고리즘으로 데이터를 처리합니다. 솔직히 말해서, MQL4는 캡슐화가 끔찍하게 부족합니다. 서로 다른 데이터 유형을 별도로 유지해야 하며 이는 오류로 가득 차 있습니다. 종종 배열 인덱싱 의 비동기화를 추적해야 합니다(매우 불쾌한 실수). MQL5가 이것을 끝낼 것이라고 생각합니다.
유라, 한 번의 반환으로 당신의 예는 물론 논리적입니다. 그러나 이 경우 모든 if는 항상 실행됩니다. 많은 반환이 있는 경우와 달리 조건이 있는 줄에 도달하는 즉시 함수에서 종료됩니다.
ForexTools, 감사합니다. 귀하의 디자인 개발을 채택했습니다.
Mathemat, 조건부 연산자 "if"에도 "else"와 같은 가젯이 있기 때문입니다.
if(식1) 문1;
else if(표현식2) 문2;
else if(표현식3) 연산자3;
else 문4;
그리고 나서 첫 번째 참 조건 후에 연산자가 실행되고 그게 전부입니다. 모든 경우 더 이상 실행되지 않습니다. 참 조건이 발견되면 이에 해당하는 연산자가 실행되고 프로그램은 이 구성 후에도 계속 작동합니다(구성에서 더 이상 검색하지 않음).
예, 나는 논쟁하지 않습니다, Sergey . 여기까지는 유라 의 디자인에 대한 이야기였습니다.
토론의 "흐름"에 또 다른 흥미로운 질문이 있습니다. 플랫폼 제한이 MQL 프로그램 작성 스타일에 어느 정도 영향을 미치나요? 예를 들어 논리적으로 분리된 일부 계산을 별도의 기능으로 분리하면 코드를 작성, 이해/읽기 및 지원하기가 더 쉽습니다. 그러나 각 함수 호출 은(특히 MQL과 같은 인터프리터에서) 실행에 소요되는 추가 시간입니다. 단일 호출은 물론 중요하지 않습니다. 대부분의 경우 루프 내부에 이러한 항목을 작성해야 합니다(for int i=0; i<Bars; i++) 등. 그런 다음 코드의 아름다움(나중에 작성한 내용을 이해할 수 있도록 함수 형태로) 또는 실행 속도(동일한 조각을 복사하여 붙여넣기) 중에서 더 중요한 것이 무엇인지 결정하기 시작합니다. 다음 틱이 도착하기 전에 사이클에 모든 것을 해결할 시간이 있습니까?)
각각의 특정한 경우 - 황금 평균의 선을 긋는 결정 - 자체가 분명하지만 .... 누가 이 문제로 어려움을 겪고 있습니까?
나는 첫 페이지의 같은 스레드에 간단한 연구 결과를 게시했습니다. 내 계산량(작음)으로 함수에 매우 만족합니다. 심지어 한 줄도 됩니다. 그러나 여기 지점에는 다른 의견이 있습니다.
아마 그럴 것이다. 나는 고대 언어 Trubo Pascual이 이상적이라고 생각하곤 했습니다. 기능을 구조화할 가능성이 있습니다. 즉. 함수 내에서 함수 선언 C는 이것을 허용하지 않습니다. 그리고 지금은 비슷한 일을 하려고 합니다. 하지만 실제로는 C 플랫폼에서 말이죠. 물론 이것은 외관상일 뿐입니다.
이제 더 정확하게는 Sergey ?
Раньше я считал идеальным древний язык Трубо Паскуаль. Там есть возможность структурирования функций, т.е. объявление функций в функциях.
그런가요? 개인적으로 한때 C로 프로그래밍 언어를 공부하기 시작했습니다. 이제 저는 C와 C++의 두 가지를 압니다. 그리고 나는 그것이 공부하는 데 전혀 다른 것을 끌어들이지 않는다고 말해야 합니다. 함수 내에서 함수를 선언해야 하는 이유는 무엇입니까? 개인적으로 C, C++에서만 자랐기 때문에 이 기술은 이해할 수 없습니다.
그리고 지금 이해합니다. 여섯 번째 호출 순서까지 함수가 있는 경우 다른 호출 순서의 모든 기능을 하나의 힙에 혼합하는 것이 항상 편리한 것은 아닙니다. 호출 구조의 일반적인 보기가 손실됩니다. 그리고 Trubo Pascual에서는 키 처리를 수행하는 여러 주요 기능과 모든 작은 하위 기능이 내부에 숨겨져 있어 모든 것이 편리합니다.
그러나 이것은 아마도 습관의 문제일 것입니다. 오랫동안 나는 그것에 대해 아무 것도 쓰지 않았습니다. 그리고 나는 그것을 정말로 후회하지 않습니다.
함수 내에서 함수를 선언해야 하는 이유는 무엇입니까? 개인적으로 C, C++에서만 자랐기 때문에 이 기술은 이해할 수 없습니다.
"세상에는 우리 현자들이 꿈도 꾸지 못한 일이 많이 있습니다, 친구 Horatio님."
이것은 자체적인 매력이 있습니다. 말하자면, 캡슐화 내의 캡슐화입니다. 그러나 진지하게, 다른 모든 것과 마찬가지로 현명하게 사용한다면 정말 유용합니다.
수학 나는 고대 언어인 Troubeau Pascual이 이상적이라고 생각하곤 했습니다.
나는 또한 그것으로 돌아갈 생각을 하고 있다 - 적어도 델파이의 DLL 형태로, 나는 가장 단순하지만 필요한 일(예를 들어, 상인과의 같은 진부한 대화)을 하기 위해 MQL에서 변태하는 것에 지쳤습니다.
- 형님의 강점은 무엇입니까!?
- 수업에 강하다, 형제여!
내 생각에, 수업보다 더 나은 것은 아직 예측되지 않았습니다. 클래스 내에서 private 함수를 선언하고 이에 사용할 public 함수를 선언합니다. 아름답고 강력합니다. 함수와 변수를 상속하고 계층 구조를 생각하십시오. 복잡한 데이터 구조를 생성하여 데이터를 캡슐화합니다. 표준 템플릿 라이브러리의 범용 알고리즘으로 데이터를 처리합니다. 솔직히 말해서, MQL4는 캡슐화가 끔찍하게 부족합니다. 서로 다른 데이터 유형을 별도로 유지해야 하며 이는 오류로 가득 차 있습니다. 종종 배열 인덱싱 의 비동기화를 추적해야 합니다(매우 불쾌한 실수). MQL5가 이것을 끝낼 것이라고 생각합니다.