EA 루핑도 나쁜 매너라고 생각합니다. 시작 주기가 끝난 후에만 매개변수를 변경하는 것은 매우 논리적입니다. Topikstarter는 문제가 그의 끝없는 루프에 있다는 것을 이해하지 않을 수 없었습니다. 그는 아마추어가 아니다. 그러나 첫 번째 메시지에서 EA의 무한 순환에 대한 단어를 쓰지 않았습니다. 나는 개인적으로 Expert Advisors에서 그러한 시스템을 만들지 않았지만 게시물로 판단하여 내가 이해하는 것처럼 이것은 이전의 경우가 아니 었 습니다. 루프 된 Expert Advisors의 매개 변수가있는 창이 열리지 않았습니다. 이것은 TS 진술 " 이는 새로운 MT4 빌드와 기존 EA의 근본적인 비호환성을 초래합니다. "는 사실이 아님을 의미합니다. 이전 MT4 빌드에서 이러한 EA는 매개변수 변경을 허용하지 않았습니다. 주기가 완료되었습니다.
EventSetMillisecondTimer는 실제로 문제를 해결합니다. 하지만 이 기능이 나온 지 얼마나 되었나요? 이전에는 EventSetTimer만 없었습니까? 1초의 최소 호출 간격으로 이러한 이벤트 는 실제 거래를 위한 시스템을 작성할 때 완전히 쓸모가 없습니다 .
타이머 도움말에는 이 기능에 대한 참조가 아직 없습니다! EventSet에 들어갈 때 힌트로 우연히 발견했습니다.
그러나 제 생각에는 변수 초기화와 관련하여 새로운 MQL 4/5에는 하나의 문제와 하나의 불일치가 있습니다. 즉, 초기화 해제 및 초기화 중에 전역 변수 의 동적 개체가 삭제되고 재생성되지 않습니다. 즉, 전역 변수에서 동적으로 생성된 객체의 생성자에서 EA의 매개변수를 읽고 추가 작업을 수행하면 매개변수가 변경될 때 매개변수가 변경되지 않은 것처럼 EA가 계속 작동합니다. 제 생각에는 이것은 논리적이지 않으며 전역 변수는 어드바이저 초기화 해제 후에 초기화를 해제하고 어드바이저 초기화 전에 다시 초기화해야 합니다. 이것은 OnInit 및 OnDeinit에서 이러한 변수를 초기화 및 삭제하여 현재 해결되고 있습니다.
AntFX : 그러나 제 생각에는 변수 초기화와 관련하여 새로운 MQL 4/5에는 하나의 문제와 하나의 불일치가 있습니다. 즉, 초기화 해제 및 초기화 중에 전역 변수 의 동적 개체가 삭제되고 재생성되지 않습니다. 즉, 전역 변수에서 동적으로 생성된 객체의 생성자에서 EA의 매개변수를 읽고 추가 작업을 수행하면 매개변수가 변경될 때 매개변수가 변경되지 않은 것처럼 EA가 계속 작동합니다. 제 생각에는 이것은 논리적이지 않으며 전역 변수는 어드바이저 초기화 해제 후에 초기화를 해제하고 어드바이저 초기화 전에 다시 초기화해야 합니다. 이것은 OnInit 및 OnDeinit에서 이러한 변수를 초기화 및 삭제하여 현재 해결되고 있습니다.
예, 이것은 특히 문서( 여기도 여기도아님 )가 이제 로딩이 초기화 이벤트와 1:1로 연결되지 않는다는 사실에 초점을 맞추지 않는다는 점을 고려하면 실제 레이크입니다. 다음은 단어입니다.
전역 변수는 프로그램이 클라이언트 터미널의 메모리에 로드된 직후에 한 번 초기화됩니다.
후속 매개변수 변경으로 인해 초기화 해제 및 초기화가 발생한다는 사실에 대해 개발자의 주의를 끌기에는 분명히 충분하지 않지만 해당 언로딩 및 로드는 없을 것입니다.
denkir : 좋든 나쁘든 이건 철학적인 질문인데... 0.0에 대한 문서에서 이 정보가 좋지 않다는 사실...
게다가 제 기억이 맞다면 이전에는 이런 일이 없었습니다. 다시 말해서, 이것은 프로그래머의 "편의성"을 위해 특별히 추가된 "기능"이지만 기존 코드의 불변성을 위반하는 것입니다. 초기화 규칙). 따라서 새 버전의 소프트웨어와 이전 코드의 호환성을 유지한다는 흔들리지 않는 원칙은 가능한 한 존중되지 않습니다.
새로운 기능과 최적화에 반대하는 사람은 없습니다. 그러나 오래된 코드를 깨뜨리지 않도록 왜 만들지 않습니까? 특히 이러한 새로운 초기화의 경우 #property strict와 유추하여 추가적인 전처리기 명령을 할당하는 것이 상당히 가능했습니다. 예를 들어 #property lazyinit를 만들고 프로그래머가 코드에 지정한 경우(즉, 명시적으로, 이는 그가 mql의 새로운 초기화를 알고 있음을 의미함) 최적화된 최적화에 만족합니다. 그리고 지정하지 않으면 이전 코드가 전역 변수 가 남을 수 있는 곳을 삽질하거나 잡는 일 없이 안정적으로 작동하게 되어 기쁩니다. 이제는 선언할 뿐만 아니라 OnInit에서 별도로 초기화해야 합니다. 이러한 각 변수에 대해 한 줄의 코드 대신 2개가 있습니다.
글쎄, 홍수가 자란 ...
EA 루핑도 나쁜 매너라고 생각합니다. 시작 주기가 끝난 후에만 매개변수를 변경하는 것은 매우 논리적입니다. Topikstarter는 문제가 그의 끝없는 루프에 있다는 것을 이해하지 않을 수 없었습니다. 그는 아마추어가 아니다. 그러나 첫 번째 메시지에서 EA의 무한 순환에 대한 단어를 쓰지 않았습니다. 나는 개인적으로 Expert Advisors에서 그러한 시스템을 만들지 않았지만 게시물로 판단하여 내가 이해하는 것처럼 이것은 이전의 경우가 아니 었 습니다. 루프 된 Expert Advisors의 매개 변수가있는 창이 열리지 않았습니다. 이것은 TS 진술 " 이는 새로운 MT4 빌드와 기존 EA의 근본적인 비호환성을 초래합니다. "는 사실이 아님을 의미합니다. 이전 MT4 빌드에서 이러한 EA는 매개변수 변경을 허용하지 않았습니다. 주기가 완료되었습니다.
EventSetMillisecondTimer는 실제로 문제를 해결합니다. 하지만 이 기능이 나온 지 얼마나 되었나요? 이전에는 EventSetTimer만 없었습니까? 1초의 최소 호출 간격으로 이러한 이벤트 는 실제 거래를 위한 시스템을 작성할 때 완전히 쓸모가 없습니다 .
타이머 도움말에는 이 기능에 대한 참조가 아직 없습니다! EventSet에 들어갈 때 힌트로 우연히 발견했습니다.
그러나 제 생각에는 새로운 MQL 4/5에 한 가지 문제와 한 가지 불일치가 있습니다. 초기화 해제 및 초기화 중에 전역 변수 의 동적 개체가 삭제 및 재생성되지 않습니다...
그러나 제 생각에는 변수 초기화와 관련하여 새로운 MQL 4/5에는 하나의 문제와 하나의 불일치가 있습니다. 즉, 초기화 해제 및 초기화 중에 전역 변수 의 동적 개체가 삭제되고 재생성되지 않습니다. 즉, 전역 변수에서 동적으로 생성된 객체의 생성자에서 EA의 매개변수를 읽고 추가 작업을 수행하면 매개변수가 변경될 때 매개변수가 변경되지 않은 것처럼 EA가 계속 작동합니다. 제 생각에는 이것은 논리적이지 않으며 전역 변수는 어드바이저 초기화 해제 후에 초기화를 해제하고 어드바이저 초기화 전에 다시 초기화해야 합니다. 이것은 OnInit 및 OnDeinit에서 이러한 변수를 초기화 및 삭제하여 현재 해결되고 있습니다.
예, 이것은 특히 문서( 여기도 여기도 아님 )가 이제 로딩이 초기화 이벤트와 1:1로 연결되지 않는다는 사실에 초점을 맞추지 않는다는 점을 고려하면 실제 레이크입니다. 다음은 단어입니다.
전역 변수는 프로그램이 클라이언트 터미널의 메모리에 로드된 직후에 한 번 초기화됩니다.
후속 매개변수 변경으로 인해 초기화 해제 및 초기화가 발생한다는 사실에 대해 개발자의 주의를 끌기에는 분명히 충분하지 않지만 해당 언로딩 및 로드는 없을 것입니다.
예, 이것은 특히 문서( 여기도 여기도 아님 )가 이제 로딩이 초기화 이벤트와 1:1로 연결되지 않는다는 사실에 초점을 맞추지 않는다는 점을 고려하면 실제 레이크입니다. 다음은 단어입니다.
전역 변수는 프로그램이 클라이언트 터미널의 메모리에 로드된 직후에 한 번 초기화됩니다.
후속 매개변수 변경으로 인해 초기화 해제 및 초기화가 발생한다는 사실에 대해 개발자의 주의를 끌기에는 분명히 충분하지 않지만 해당 언로딩 및 로드는 없을 것입니다.
예, 변수를 로드/언로드하고 다시 초기화할 필요가 없습니다. 프로그래머는 변수 초기화를 처리해야 합니다.
예, 변수를 로드/언로드하고 다시 초기화할 필요가 없습니다. 프로그래머는 변수 초기화를 처리해야 합니다.
바로 이 초기화가 수행될 때 명확하게 말하지 않는다는 점입니다. 전역 변수가 있는 코드:
int x = 0;
이것은 또한 초기화입니다. 그러나 설명서에는 MK의 관점에서 이것이 초기화 가 아니라고 명시적으로 명시되어 있지 않습니다.
엄밀히 말하면 MT에는 두 가지 다른 초기화가 있습니다. 하나는 프로그램이 로드될 때 수행되고 두 번째는 OnInit가 호출되는 순간 "환경"이 변경될 때 수행됩니다. 파헤쳐야 하는건 안타까운 일입니다.
프로그램을 시작할 때 - 콜드 스타트. 변수에 대한 메모리 할당과 초기 값을 사용한 초기화가 있습니다.
직장에서 - 따뜻한 시작. 여기서 프로그래머는 변수 초기화를 처리해야 하며 이는 좋은 일입니다.
프로그램을 시작할 때 - 콜드 스타트. 변수에 대한 메모리 할당과 초기 값을 사용한 초기화가 있습니다.
직장에서 - 따뜻한 시작. 여기서 프로그래머는 변수 초기화를 처리해야 하며 이는 좋은 일입니다.
좋든 나쁘든 이건 철학적인 질문인데... 0.0에 대한 문서에서 이 정보가 좋지 않다는 사실...
게다가 제 기억이 맞다면 이전에는 이런 일이 없었습니다. 다시 말해서, 이것은 프로그래머의 "편의성"을 위해 특별히 추가된 "기능"이지만 기존 코드의 불변성을 위반하는 것입니다. 초기화 규칙). 따라서 새 버전의 소프트웨어와 이전 코드의 호환성을 유지한다는 흔들리지 않는 원칙은 가능한 한 존중되지 않습니다.
새로운 기능과 최적화에 반대하는 사람은 없습니다. 그러나 오래된 코드를 깨뜨리지 않도록 왜 만들지 않습니까? 특히 이러한 새로운 초기화의 경우 #property strict와 유추하여 추가적인 전처리기 명령을 할당하는 것이 상당히 가능했습니다. 예를 들어 #property lazyinit를 만들고 프로그래머가 코드에 지정한 경우(즉, 명시적으로, 이는 그가 mql의 새로운 초기화를 알고 있음을 의미함) 최적화된 최적화에 만족합니다. 그리고 지정하지 않으면 이전 코드가 전역 변수 가 남을 수 있는 곳을 삽질하거나 잡는 일 없이 안정적으로 작동하게 되어 기쁩니다. 이제는 선언할 뿐만 아니라 OnInit에서 별도로 초기화해야 합니다. 이러한 각 변수에 대해 한 줄의 코드 대신 2개가 있습니다.