이 접근 방식으로 - "모든 것이 있는" 기본 클래스에서 상속 - 모든 것이 작동하지만 여러 클래스 필드를 만들고 각 클래스 필드에 여러 필드를 추가하려고 할 때까지는 모든 것을 이겨냅시다. 동적 클래스 배열
그리고 우리는 Save(int hndl) 메서드 자체를 얻습니다. 기본 클래스에서 구현할 수 없습니다. 이 메서드는 본질적으로 인터페이스가 될 것입니다. 논의한 바와 같이 전혀 필요하지 않습니다. 인터페이스 없이도 작성할 수 있습니다.
이것으로 괜찮습니다. 그것은 모두 취향과 작업의 문제입니다. 나는 일반적으로 코드 유연성에 대한 노력을 최대화합니다 - 최소한의 제스처 - 결과는 해결 된 새로운 문제입니다. 용어를 용서하십시오)))
그러나 문제는 파일에 저장을 구현할 때 서로 다른 유형의 총 레코드 수를 설명해야 하는 파일 헤더를 개발 해야 한다는 것입니다. 그러면 논리/저장 순서를 잃지 않아도 됩니다. 모든 것을 올바르게 읽기 위한 데이터 .... 그리고 마지막은 한 클래스의 하나 이상의 필드가 변경된 경우입니다.
기본 클래스에서 이러한 "가벼운" 상속의 복잡성인 IMHO는 작은 데이터베이스의 개발 및 유지 관리, 모든 클래스의 변경 사항에 대한 지속적인 모니터링으로 귀결됩니다.
예, 이 모든 것은 이해할 수 있지만 잘 정립된 "mucl this is not C for you"에 대해서는 작업별로 잘 구조화된 코드에 의존하는 것은 아무 소용이 없다고 덧붙일 수 있습니다. MQL 작업은 항상 고도로 전문화되고 큰 크기를 재사용합니다. 코드는 종종 비효율적입니다
추신: IMHO, MQL 코드의 주요 작업은 테스터에서 사용하거나 한 틱에서 코드를 실행하기 위해 가능한 한 빠르게 하는 것입니다. 틱을 건너뛰지 않고 모든 것이 명확해 보이지만 제한 사항도 있습니다. 연결이 끊어지고 PC / 터미널이 다시 시작되는 상황을 무시할 수 없으며 여기에서 아름답고 구조화된 코드뿐만 아니라 최적의 위치를 찾아야 합니다.
추신: 솔루션이 좋습니다. RowCount() 및 ColCount() 메서드를 RowCount 및 ColCount 구조의 필드로 바꿔야 호출이 줄어들지만 일반적으로 모든 것이 예상대로 작동합니다.
불행히도 모든 것이 우리가 원하는 만큼 행복한 것은 아닙니다. 기본 복사 연산자 를 사용하여 배열을 복사하는 MQL에는 오랜 버그가 있습니다. 한 배열에서 다른 배열로 요소의 ArrayCopy만 있습니다. 그리고 최종 배열의 크기는 소스와 동기화되지 않습니다(잘리지 않음). 저것들. A(10), B(20)라고 하면 B=A 후에 B(20)도 갖게 됩니다. 요소의 절반은 A의 요소로 대체되고 나머지는 동일하게 유지됩니다. 이것은 확실히 = 연산자에서 기대하는 것과 다릅니다. 따라서 배열의 경우 고유한 연산자를 작성해야 합니다.
솔직히 이 버그는 이미 수정되었다고 생각했습니다. 그러나 나는 확인했습니다 - 상황이 여전히 거기에 있습니다.
불행히도 모든 것이 우리가 원하는 만큼 행복한 것은 아닙니다. 기본 복사 연산자를 사용하여 배열을 복사하는 MQL에는 오랜 버그가 있습니다. 한 배열에서 다른 배열로 요소의 ArrayCopy만 있습니다. 그리고 최종 배열의 크기는 소스와 동기화되지 않습니다(잘리지 않음). 저것들. A(10), B(20)라고 하면 B=A 후에 B(20)도 갖게 됩니다. 요소의 절반은 A의 요소로 대체되고 나머지는 동일하게 유지됩니다. 이것은 확실히 = 연산자에서 기대하는 것과 다릅니다. 따라서 배열의 경우 고유한 연산자를 작성해야 합니다.
솔직히 이 버그는 이미 수정되었다고 생각했습니다. 그러나 나는 확인했습니다 - 상황이 여전히 거기에 있습니다.
이것은 정확히 내가 남긴 것입니다. 그러나 처음에 나는 그것을했습니다.
이 접근 방식으로 - "모든 것이 있는" 기본 클래스에서 상속 - 모든 것이 작동하지만 여러 클래스 필드를 만들고 각 클래스 필드에 여러 필드를 추가하려고 할 때까지는 모든 것을 이겨냅시다. 동적 클래스 배열
그리고 우리는 Save(int hndl) 메서드 자체를 얻습니다. 기본 클래스에서 구현할 수 없습니다. 이 메서드는 본질적으로 인터페이스가 될 것입니다. 논의한 바와 같이 전혀 필요하지 않습니다. 인터페이스 없이도 작성할 수 있습니다.
이것으로 괜찮습니다. 그것은 모두 취향과 작업의 문제입니다. 나는 일반적으로 코드 유연성에 대한 노력을 최대화합니다 - 최소한의 제스처 - 결과는 해결 된 새로운 문제입니다. 용어를 용서하십시오)))
그러나 문제는 파일에 저장을 구현할 때 서로 다른 유형의 총 레코드 수를 설명해야 하는 파일 헤더를 개발 해야 한다는 것입니다. 그러면 논리/저장 순서를 잃지 않아도 됩니다. 모든 것을 올바르게 읽기 위한 데이터 .... 그리고 마지막은 한 클래스의 하나 이상의 필드가 변경된 경우입니다.
기본 클래스에서 이러한 "가벼운" 상속의 복잡성인 IMHO는 작은 데이터베이스의 개발 및 유지 관리, 모든 클래스의 변경 사항에 대한 지속적인 모니터링으로 귀결됩니다.
이 같은))))
이 같은))))
예, 이 모든 것은 이해할 수 있지만 잘 정립된 "mucl this is not C for you"에 대해서는 작업별로 잘 구조화된 코드에 의존하는 것은 아무 소용이 없다고 덧붙일 수 있습니다. MQL 작업은 항상 고도로 전문화되고 큰 크기를 재사용합니다. 코드는 종종 비효율적입니다
추신: IMHO, MQL 코드의 주요 작업은 테스터에서 사용하거나 한 틱에서 코드를 실행하기 위해 가능한 한 빠르게 하는 것입니다. 틱을 건너뛰지 않고 모든 것이 명확해 보이지만 제한 사항도 있습니다. 연결이 끊어지고 PC / 터미널이 다시 시작되는 상황을 무시할 수 없으며 여기에서 아름답고 구조화된 코드뿐만 아니라 최적의 위치를 찾아야 합니다.
2. operator=를 설명하고 기본 복사 연산자를 사용하는 해킹이 있습니까? .... 즉. ::= 를 호출 하는 방법
방법이 있으며 평소와 같이 솔루션은 간단합니다.
행렬 A를 초기화한 다음 C를 초기화합니다.
먼저 새 행렬 B = A를 할당하고 출력한 다음 B=C를 출력하고 출력합니다.
2020.04.21 00:35:50.559 tst (EURUSD,H1) 0 1 2 3 4
2020.04.21 00:35:50.559 tst (EURUSD,H1) 5 6 7 8 9
2020.04.21 00:35:50.560 tst (EURUSD,H1) 100 101
2020.04.21 00:35:50.560 tst (EURUSD,H1) 102 103
2020.04.21 00:35:50.560 tst (EURUSD,H1) 104 105
2020.04.21 00:35:50.560 tst (EURUSD,H1) 106 107
2020.04.21 00:35:50.560 tst (EURUSD,H1) 108 109
본질 - 구조를 구조로 감싸고 구조를 다시 감싸야합니다 .... 내 기술 용어에 대해 사과드립니다))))
추신: 솔루션이 좋습니다. RowCount() 및 ColCount() 메서드를 RowCount 및 ColCount 구조의 필드로 바꿔야 호출이 줄어들지만 일반적으로 모든 것이 예상대로 작동합니다.
진심이야?
그리고 그게 무슨 문제인지, 2012년부터 이 문제를 해결해 온 사람이 있으니 간섭하지 마세요. 그 사람이 더 잘 압니다.
그리고 그게 무슨 문제인지, 2012년부터 이 문제를 해결해 온 사람이 있으니 간섭하지 마세요. 그 사람이 더 잘 압니다.
평면적 사고
작업은 MQL 언어의 기술적 기능을 아는 것이므로 https://docs.microsoft.com/en-us/archive/msdn-magazine/2018/april/test-run-understanding-lstm- cell-using-csharp
"이마에"를 이식하는 것이 가능했습니다. 이제 이 작업이 해결되었습니다. 하나의 가정으로 예제의 모든 기능을 일대일로 이식합니다. float[][] result --> SMatrix result
방법이 있으며 평소와 같이 솔루션은 간단합니다.
행렬 A를 초기화한 다음 C를 초기화합니다.
먼저 새 행렬 B = A를 할당하고 출력한 다음 B=C를 출력하고 출력합니다.
추신: 솔루션이 좋습니다. RowCount() 및 ColCount() 메서드를 RowCount 및 ColCount 구조의 필드로 바꿔야 호출이 줄어들지만 일반적으로 모든 것이 예상대로 작동합니다.
불행히도 모든 것이 우리가 원하는 만큼 행복한 것은 아닙니다. 기본 복사 연산자 를 사용하여 배열을 복사하는 MQL에는 오랜 버그가 있습니다. 한 배열에서 다른 배열로 요소의 ArrayCopy만 있습니다. 그리고 최종 배열의 크기는 소스와 동기화되지 않습니다(잘리지 않음). 저것들. A(10), B(20)라고 하면 B=A 후에 B(20)도 갖게 됩니다. 요소의 절반은 A의 요소로 대체되고 나머지는 동일하게 유지됩니다. 이것은 확실히 = 연산자에서 기대하는 것과 다릅니다. 따라서 배열의 경우 고유한 연산자를 작성해야 합니다.
솔직히 이 버그는 이미 수정되었다고 생각했습니다. 그러나 나는 확인했습니다 - 상황이 여전히 거기에 있습니다.
불행히도 모든 것이 우리가 원하는 만큼 행복한 것은 아닙니다. 기본 복사 연산자를 사용하여 배열을 복사하는 MQL에는 오랜 버그가 있습니다. 한 배열에서 다른 배열로 요소의 ArrayCopy만 있습니다. 그리고 최종 배열의 크기는 소스와 동기화되지 않습니다(잘리지 않음). 저것들. A(10), B(20)라고 하면 B=A 후에 B(20)도 갖게 됩니다. 요소의 절반은 A의 요소로 대체되고 나머지는 동일하게 유지됩니다. 이것은 확실히 = 연산자에서 기대하는 것과 다릅니다. 따라서 배열의 경우 고유한 연산자를 작성해야 합니다.
솔직히 이 버그는 이미 수정되었다고 생각했습니다. 그러나 나는 확인했습니다 - 상황이 여전히 거기에 있습니다.
버그가 최근에 언급되었습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MQL5의 OOP에 대한 질문
Sergey Dzyublik , 2020.04.18 17:48
그런 다음 귀하의 용어에 따라 기본 할당 연산자를 호출하면 "불완전한 데이터 유형"이 생성될 수 있습니다.
2019.05.03 일자 버그는 여전히 수정되지 않았습니다: https://www.mql5.com/en/forum/1111/page2451#comment_11556395
아이디어에 따르면 위의 줄은 버그를 우회해야 합니다.
아이디어에 따르면 위의 줄은 버그를 우회해야 합니다.
아, 네, 바로 눈치채지 못했는데... 바로 ArrayCopy 를 작성할 수 있게 되었습니다. 그렇다면 이 SMATRIX 개스킷이 필요한 이유는 무엇입니까? ..
아, 네, 바로 눈치채지 못했는데... 바로 ArrayCopy를 작성할 수 있게 되었습니다. 그렇다면 이 SMATRIX 개스킷이 필요한 이유는 무엇입니까? ..
MT 개발자는 내장 컴파일러 메커니즘을 사용하는 것이 일반 함수를 호출하는 것보다 빠를 것이라고 항상 작성합니다.
시간과 관심이 있다면 ArrayCopy 로 내 버전과 당신 버전의 속도를 확인하십시오.
속도는 조금 이따 확인할게요 지금은 PC방이 레슨으로 바쁘네요