Ilyas : 따라서 제어를 터미널로 다시 반환하지 않고 DLL의 Fn 내부에 "무한" 루프에 "매달"했습니다. 이 얼마나 평범한 결말인가!
이러한 동작이 필요한 경우 DLL의 Fn 내부에서 별도의 FnStop 함수에 설정된 플래그에 의해 중지될 수 있는 주기로 별도의 스레드를 시작해야 하고 DLL_PROCESS_DETACH
제어를 되돌리지 않았다는 사실은 예를 들어 만든 것이지만 mql 스레드를 차단하지 않도록 while은 별도의 스레드에서 실행되어야 함은 분명합니다. 그러나 다른 스레드에서 실행할 때 동일한 동작이 발생합니다. 문제는 DLL_PROCESS_DETACH에 있습니다. 이 식별자는 이미 존재하는 Detach 플래그에 대해 작동하지 않습니다. 예, 우리는 이미 별도의 내보낸 함수 를 만들고 이를 통해 플래그를 제어해야 한다고 썼습니다. 그러나 예제와 같이 DLL_PROCESS_DETACH의 플래그는 작동하지 않습니다. 따라서 터미널에 오류가 있을 수 있지만 DLL_PROCESS_DETACH가 플래그를 다른 상태로 전송해야 하는 것이 논리적입니다. 이 상태를 받은 while 루프는 루프를 종료하고 경로에서 발생하는 모든 작업이 실행되고 Fn() 함수 자체가 완료됩니다. 그리고 그 후에야 dll을 언로드해야 합니다! 그러나 이것은 발생하지 않습니다. 터미널의 숨겨진 메커니즘에 의해 dll의 일종의 조기 언로드가 나타나므로 충돌이 발생합니다.
제어를 되돌리지 않았다는 사실은 예를 들어 만든 것이지만 mql 스레드를 차단하지 않도록 while은 별도의 스레드에서 실행되어야 함은 분명합니다. 그러나 다른 스레드에서 실행할 때 동일한 동작이 발생합니다. 문제는 DLL_PROCESS_DETACH에 있습니다. 이 식별자는 이미 존재하는 Detach 플래그에 대해 작동하지 않습니다. 예, 우리는 이미 별도의 내보낸 함수 를 만들고 이를 통해 플래그를 제어해야 한다고 썼습니다. 그러나 예제와 같이 DLL_PROCESS_DETACH의 플래그는 작동하지 않습니다. 따라서 터미널에 오류가 있을 수 있지만 DLL_PROCESS_DETACH가 플래그를 다른 상태로 전송해야 하는 것이 논리적입니다. 이 상태를 받은 while 루프는 루프를 종료하고 경로에서 발생하는 모든 작업이 실행되고 Fn() 함수 자체가 완료됩니다. 그리고 그 후에야 dll을 언로드해야 합니다! 그러나 이것은 발생하지 않습니다. 터미널의 숨겨진 메커니즘에 의해 dll의 일종의 조기 언로드가 나타나므로 충돌이 발생합니다.
어디 보자. 터미널 쓰레드에서 dll에서 주기를 실행하면 멈추고, 별도의 쓰레드에서 detach()를 하면 터미널이 에러로 크래시가 나나요?
불행히도 현재 MT4/MT5에서 함수 포인터 유형의 가능성은 매우 제한적이며 여러 가지 결함으로 인해 실용적이지 않습니다. #(MT5(빌드 2118)에서 수정되지 않음)"typedef 내에서 동일한 함수 서명을 재사용할 때 컴파일 오류". #(MT5(build2118)에서 수정되지 않음)"typedef로 작업할 때 명시적 특수화와 함께 템플릿 함수를 사용하면 템플릿 함수 코드가 생성되지 않습니다."
네임스페이스의 예상되는 구현을 고려하여 결함 수정의 일부로 다음 C++ 유사한 동작 에 대한 지원을 구현할 가능성을 고려해 보시기 바랍니다.
//#include <iostream>template < typename T>
class A{
public :
typedefvoid (*callback)(T&); //class namespace for function pointer type
callback f_ptr;
T data;
};
template < typename T>
class B{
public :
typedefvoid (*callback)(T&); //class namespace for function pointer type
callback f_ptr;
};
template < typename T>
void func(T& value){
++value;
}
voidOnStart (){
//int main(){
A< int > a;
B< int > b;
a.f_ptr = func< int >; // automatic code generation of templates functions
b.f_ptr = a.f_ptr; // assignment operation for function pointers with the same function signatures and different function pointer types.int x = 1 ;
b.f_ptr(x);
printf ( "%d\r\n" , x); //2printf ( "%d\r\n" , b.f_ptr == a.f_ptr); //1 // equal operation for function pointers with the same function signatures and different function pointer types.
}
MT5(빌드 2118), typedef 기능의 버그 수정을 얼마나 기다려야 합니까? 일종의 넌센스 - typedef 를 사용하는 원시적인 예에서 왼쪽으로 한 단계 더 나아가 개발을 방해하는 많은 버그 입니다.
Vladimir Simakov : 어디 보자. 터미널 쓰레드에서 dll에서 주기를 실행하면 멈추고, 별도의 쓰레드에서 detach()를 하면 터미널이 에러로 크래시가 나나요?
확실히 그런 방식은 아닙니다. 루프를 실행하면 잘 작동합니다. 문제는 프로그램을 강제로 중지하고 루프에 플래그를 전달하여 루프를 종료하고 실행 중인 기능을 종료할 때입니다. 그러나 터미널에서는 dll의 초기 언로드가 이미 작동했기 때문에 루프를 올바르게 종료하고 실행 중인 기능을 완료할 수 없습니다. 우리는 옷걸이를 얻습니다. 플래그 상태가 전달되기 전에 dll이 언로드되고 Fn 기능이 완료되지 않으며 조기 언로드는 모든 것을 중단합니다.
차단 모드에서 문제가 더 잘 보이기 때문에 모든 코드를 작성하지 않도록 터미널 스트림에서 예제로 수행했습니다. 나는 이미 주기 플래그에 대해 별도의 기능을 시작했으며 실행 중인 주기는 다른 스레드에서 작동하지만 모두 동일한 동작입니다. 그리고 차단되지 않은 mql 코드에서 시도할 때 루프를 종료하기 위해 플래그를 다른 상태로 전송하는 함수를 사용합니다. 터미널은 실행 중인 사이클이 완료될 때까지 기다리지 않으며 사이클이 회전하는 곳에서 Fn 기능이 완료되는 것을 허용하지 않습니다. 터미널은 Fn 기능이 완료될 때까지 기다리지 않고 dll의 조기 언로드를 즉시 수행합니다. 이것이 문제가 있는 곳입니다.
더엑스퍼트 : 따라서 올바른 예를 들어 주십시오. 첨부 파일은 그대로 두십시오. 스레드의 생성/제거를 명시적으로 직접 관리하십시오.
잠금 모드에서는 문제를 더 잘 볼 수 있습니다. 사실, 플래그의 상태가 어떻게 변경되는지는 중요하지 않습니다. 진입점 또는 독립 실행형 기능. 차단 모드의 경우 제어가 다시 전송되지 않고 플래그 변경 기능을 호출하는 데 작동하지 않기 때문에 진입점이 더 좋습니다. 이러한 이유로 예를 들어 세부 정보를 첨부하십시오. 나는 첨부 파일 세부 사항을 그대로두고 비 차단 모드의 작업 프로젝트에서 동일한 동작을 조언 한대로 별도의 기능을 시작했습니다. dll의 조기 언로드가 있으며, while 루프가 회전하는 작업 기능은 행거가 도착함에 따라 완료할 시간이 없습니다.
첫 번째 ArrayPrint는 CustomRatesUpdate에 쓰여진 것이고, 두 번째 ArrayPrint는 쓰기 직후 가장 최근의 바에서 CopyRates를 사용하여 읽은 것입니다. 첫째, 차이는 시가의 마지막 자릿수에 있지만 더 중요한 것은 고가와 종가가 10배 증가한다는 것입니다.
사용자 정의 기호와 관련하여 다음과 같은 문제가 발생한 사람이 있습니까? 일반적인 따옴표는 CustomRatesUpdate 함수에 전달되지만 실제로 차트와 데이터 창에 이상한 것이 표시됩니다(이 경우 닫기 및 낮은 값은 전달된 값보다 100배 작음).
또한 단일 틱은 로그와 동일한 종가 값으로 CustomTicksAdd를 사용하여 동시에 에뮬레이트됩니다(CustomRatesUpdate 직전). 따옴표로 묶인 감소된 값의 출처는 명확하지 않습니다.
예, 나는 이해할 수없는 0이있었습니다. 100 폴드 슬립에 당신에게. 나는 0에 대한 추가 검사를 수행했지만 도움이되지 않았고 비뚤어지게 작동했으며 그러한 스파이크를 그리는 것이 정상이었습니다. 기본적으로 이 동작은 프로그램을 처음 시작할 때 관찰되었으며, 처음 시작할 때 존재하지 않는 날짜로 히스토리 파일이 생성되었습니다. 틱 폴더를 청소하고 버그가 있는 위치를 찾기 위해 코드를 수정했습니다. 피곤해서 일단 미루었지만 이 문제로 돌아가야 합니다(( 사용자 지정 기록 폴더도 확인하십시오. 날짜가 존재하지 않는 파일이 있을 수 있습니다)) 일반적으로 특정 딱정벌레가 살고 있습니다.
따라서 제어를 터미널로 다시 반환하지 않고 DLL의 Fn 내부에 "무한" 루프에 "매달"했습니다.
이 얼마나 평범한 결말인가!
이러한 동작이 필요한 경우 DLL의 Fn 내부에서 별도의 FnStop 함수에 설정된 플래그에 의해 중지될 수 있는 주기로 별도의 스레드를 시작해야 하고 DLL_PROCESS_DETACH
제어를 되돌리지 않았다는 사실은 예를 들어 만든 것이지만 mql 스레드를 차단하지 않도록 while은 별도의 스레드에서 실행되어야 함은 분명합니다.
그러나 다른 스레드에서 실행할 때 동일한 동작이 발생합니다. 문제는 DLL_PROCESS_DETACH에 있습니다. 이 식별자는 이미 존재하는 Detach 플래그에 대해 작동하지 않습니다.
예, 우리는 이미 별도의 내보낸 함수 를 만들고 이를 통해 플래그를 제어해야 한다고 썼습니다.
그러나 예제와 같이 DLL_PROCESS_DETACH의 플래그는 작동하지 않습니다.
따라서 터미널에 오류가 있을 수 있지만 DLL_PROCESS_DETACH가 플래그를 다른 상태로 전송해야 하는 것이 논리적입니다.
이 상태를 받은 while 루프는 루프를 종료하고 경로에서 발생하는 모든 작업이 실행되고 Fn() 함수 자체가 완료됩니다.
그리고 그 후에야 dll을 언로드해야 합니다!
그러나 이것은 발생하지 않습니다. 터미널의 숨겨진 메커니즘에 의해 dll의 일종의 조기 언로드가 나타나므로 충돌이 발생합니다.
당신, Fedoseev 등과 같은 무능한 사람들이 그들의 의견으로 버그와 디자인에 대한 토론에 끼어들지 않도록.
전체적으로 C++에서 MQL로 가져오고 C++에서와 동일하게 보이는 구성 및 메커니즘이 C++에서와 동일한 방식으로 작동하도록 합니다.
이것은 말도 안되는 소리이고 당신도 알고 있지만 버려야 합니다.너만 징징. 그들이 그것을 어떻게 얻었는지, 별도의 언어와 별도의 지점에 대해.
너 자신과 동정하는 사람들과 거기에 노아를 위해 별도의 지점을 엽니 다.
나는 당신에 대해 더 나은 의견을 가졌습니다. 잘못된. 그것은 일어난다. 당신은 멍청하고 ... 똑똑하지 않습니다.
제어를 되돌리지 않았다는 사실은 예를 들어 만든 것이지만 mql 스레드를 차단하지 않도록 while은 별도의 스레드에서 실행되어야 함은 분명합니다.
그러나 다른 스레드에서 실행할 때 동일한 동작이 발생합니다. 문제는 DLL_PROCESS_DETACH에 있습니다. 이 식별자는 이미 존재하는 Detach 플래그에 대해 작동하지 않습니다.
예, 우리는 이미 별도의 내보낸 함수 를 만들고 이를 통해 플래그를 제어해야 한다고 썼습니다.
그러나 예제와 같이 DLL_PROCESS_DETACH의 플래그는 작동하지 않습니다.
따라서 터미널에 오류가 있을 수 있지만 DLL_PROCESS_DETACH가 플래그를 다른 상태로 전송해야 하는 것이 논리적입니다.
이 상태를 받은 while 루프는 루프를 종료하고 경로에서 발생하는 모든 작업이 실행되고 Fn() 함수 자체가 완료됩니다.
그리고 그 후에야 dll을 언로드해야 합니다!
그러나 이것은 발생하지 않습니다. 터미널의 숨겨진 메커니즘에 의해 dll의 일종의 조기 언로드가 나타나므로 충돌이 발생합니다.
제어를 되돌려주지 않는다는 사실은 예를 들어 만든 것이지만, while은 스레드를 차단하지 않도록 별도의 스레드에서 실행되어야 함은 분명합니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
오류, 버그, 질문
Sergey Dzyublik , 2019.05.26 15:12
불행히도 현재 MT4/MT5에서 함수 포인터 유형의 가능성은 매우 제한적이며 여러 가지 결함으로 인해 실용적이지 않습니다.# (MT5(빌드 2118)에서 수정되지 않음) "typedef 내에서 동일한 함수 서명을 재사용할 때 컴파일 오류 ".
# (MT5(build 2118 )에서 수정되지 않음) "typedef로 작업할 때 명시적 특수화와 함께 템플릿 함수를 사용하면 템플릿 함수 코드가 생성되지 않습니다."
네임스페이스의 예상되는 구현을 고려하여 결함 수정의 일부로 다음 C++ 유사한 동작 에 대한 지원을 구현할 가능성을 고려해 보시기 바랍니다.
MT5(빌드 2118), typedef 기능의 버그 수정을 얼마나 기다려야 합니까?
일종의 넌센스 - typedef 를 사용하는 원시적인 예에서 왼쪽으로 한 단계 더 나아가 개발을 방해하는 많은 버그 입니다.
어디 보자. 터미널 쓰레드에서 dll에서 주기를 실행하면 멈추고, 별도의 쓰레드에서 detach()를 하면 터미널이 에러로 크래시가 나나요?
확실히 그런 방식은 아닙니다.
루프를 실행하면 잘 작동합니다.
문제는 프로그램을 강제로 중지하고 루프에 플래그를 전달하여 루프를 종료하고 실행 중인 기능을 종료할 때입니다.
그러나 터미널에서는 dll의 초기 언로드가 이미 작동했기 때문에 루프를 올바르게 종료하고 실행 중인 기능을 완료할 수 없습니다. 우리는 옷걸이를 얻습니다.
플래그 상태가 전달되기 전에 dll이 언로드되고 Fn 기능이 완료되지 않으며 조기 언로드는 모든 것을 중단합니다.
차단 모드에서 문제가 더 잘 보이기 때문에 모든 코드를 작성하지 않도록 터미널 스트림에서 예제로 수행했습니다.
나는 이미 주기 플래그에 대해 별도의 기능을 시작했으며 실행 중인 주기는 다른 스레드에서 작동하지만 모두 동일한 동작입니다.
그리고 차단되지 않은 mql 코드에서 시도할 때 루프를 종료하기 위해 플래그를 다른 상태로 전송하는 함수를 사용합니다.
터미널은 실행 중인 사이클이 완료될 때까지 기다리지 않으며 사이클이 회전하는 곳에서 Fn 기능이 완료되는 것을 허용하지 않습니다.
터미널은 Fn 기능이 완료될 때까지 기다리지 않고 dll의 조기 언로드를 즉시 수행합니다. 이것이 문제가 있는 곳입니다.
따라서 올바른 예를 들어 주십시오. 첨부 파일은 그대로 두십시오. 스레드의 생성/제거를 명시적으로 직접 관리하십시오.
잠금 모드에서는 문제를 더 잘 볼 수 있습니다. 사실, 플래그의 상태가 어떻게 변경되는지는 중요하지 않습니다. 진입점 또는 독립 실행형 기능.
차단 모드의 경우 제어가 다시 전송되지 않고 플래그 변경 기능을 호출하는 데 작동하지 않기 때문에 진입점이 더 좋습니다. 이러한 이유로 예를 들어 세부 정보를 첨부하십시오.
나는 첨부 파일 세부 사항을 그대로두고 비 차단 모드의 작업 프로젝트에서 동일한 동작을 조언 한대로 별도의 기능을 시작했습니다.
dll의 조기 언로드가 있으며, while 루프가 회전하는 작업 기능은 행거가 도착함에 따라 완료할 시간이 없습니다.
dll의 조기 언로드가 있으며, while 루프가 회전하는 작업 기능은 행거가 도착함에 따라 완료할 시간이 없습니다.
정상적인 구현에 매달릴 수 없습니다.
사용자 정의 기호와 관련하여 다음과 같은 문제가 발생한 사람이 있습니까? 일반적인 따옴표는 CustomRatesUpdate 함수에 전달되지만 실제로 차트와 데이터 창에 이상한 것이 표시됩니다(이 경우 닫기 및 낮은 값은 전달된 값보다 100배 작음).
또한 단일 틱은 로그와 동일한 종가 값으로 CustomTicksAdd를 사용하여 동시에 에뮬레이트됩니다(CustomRatesUpdate 직전). 따옴표로 묶인 감소된 값의 출처는 명확하지 않습니다.
상향:
USDCAD에서는 어떤 의미에서 "역" 상황이 발생했습니다. 기록 이후에 따옴표가 10배 증가합니다. 이것은 내가 얻는 로그입니다.
첫 번째 ArrayPrint는 CustomRatesUpdate에 쓰여진 것이고, 두 번째 ArrayPrint는 쓰기 직후 가장 최근의 바에서 CopyRates를 사용하여 읽은 것입니다. 첫째, 차이는 시가의 마지막 자릿수에 있지만 더 중요한 것은 고가와 종가가 10배 증가한다는 것입니다.
사용자 정의 기호와 관련하여 다음과 같은 문제가 발생한 사람이 있습니까? 일반적인 따옴표는 CustomRatesUpdate 함수에 전달되지만 실제로 차트와 데이터 창에 이상한 것이 표시됩니다(이 경우 닫기 및 낮은 값은 전달된 값보다 100배 작음).
또한 단일 틱은 로그와 동일한 종가 값으로 CustomTicksAdd를 사용하여 동시에 에뮬레이트됩니다(CustomRatesUpdate 직전). 따옴표로 묶인 감소된 값의 출처는 명확하지 않습니다.
예, 나는 이해할 수없는 0이있었습니다. 100 폴드 슬립에 당신에게.
이 스레드에 문제를 게시하십시오.나는 0에 대한 추가 검사를 수행했지만 도움이되지 않았고 비뚤어지게 작동했으며 그러한 스파이크를 그리는 것이 정상이었습니다.
기본적으로 이 동작은 프로그램을 처음 시작할 때 관찰되었으며, 처음 시작할 때 존재하지 않는 날짜로 히스토리 파일이 생성되었습니다.
틱 폴더를 청소하고 버그가 있는 위치를 찾기 위해 코드를 수정했습니다. 피곤해서 일단 미루었지만 이 문제로 돌아가야 합니다((
사용자 지정 기록 폴더도 확인하십시오. 날짜가 존재하지 않는 파일이 있을 수 있습니다))
일반적으로 특정 딱정벌레가 살고 있습니다.
거기에서 Slava는 사용자 정의 기호를 담당하는 것 같습니다.
문제를 상기시키기 위해.
이 버그가 이전에 언급된 적이 있습니까? 못찾 겠어요. 결론: 캐시 파일에서 최적화 결과를 로드할 때 전달 결과가 잘못 표시됩니다. 매개변수 값의 왼쪽 숫자.
최적화 탭으로 이동합니다. 당신은 전문가를 선택합니다. 이전 최적화 중 하나를 선택합니다. 백테스트가 잘 로드됩니다. 전달자는 다음을 발행합니다.
MT5, 마지막 빌드. x64.