카운터 값은 응용 프로그램 시작 시 고정되므로 이 델타는 날짜 변경의 영향을 받습니다. 시간 종속 소프트웨어가 실행 중일 때 컴퓨터에서 날짜를 심각하게 변경하는 것은 일본 전기 톱으로 러시아 남성의 접근과 방해 행위입니다. 농담으로 좋습니다.
나는 특히 애니메이션 gif에서 인터넷을 통한 시간 동기화를 보여주었습니다. 이 동기화는 기본적으로 모든 사람에게 자동이며 누군가의 참여 없이 아주 자주 일정에 따라 발생합니다. 그리고 이 동기화가 측정 중에 발생할 수 있다는 보장은 없습니다. 나는 GetMicrosecondCount()의 이 기능에 대해 이미 알고 있고 이 함수가 GetTickCount보다 훨씬 더 느리다는 것을 알고 있기 때문에 나 자신에 대해 걱정하지 않습니다. 그러나 이 스레드를 읽지 않고 이 기능에 대한 도움말을 아주 주의 깊게 읽는 다른 사람들은 실제 Expert Advisor의 논리에서 GetMicrosecondCount를 사용하면 문제에 부딪힐 수 있습니다. 테스트 중에는 모든 것이 정상이지만 예정된 시간 동기화 또는 겨울(여름) 시간으로 전환하는 시간에 실제 거래 중에 OH가 발생할 수 있습니다. 특히 시간이 감소하고 ulong 유형의 오버플로가 발생하면 OH가 발생할 수 있습니다. 그건 그렇고, 문서화되지 않은 이 새로운 정보는 동시에 여러 타이머의 작업을 구성하는 현재 생성 중인 다중 타이머 클래스의 논리를 크게 조정했습니다. 이 클래스의 작업에서 마이크로초 함수는 Might와 Main과 함께 사용되었습니다. 그러나 이제 속도를 높이는 것을 포함하여 15625μs의 정확도를 희생해야 한다는 것을 이해합니다. 페이버 턴 플리즈. 그는 비열하지 않습니다. 그는 단지 비열하지만 그는 착합니다. 젠장, 이제 나도 금지 :((
나는 특히 애니메이션 gif에서 인터넷을 통한 시간 동기화를 보여주었습니다. 기본적으로 이러한 동기화는 모든 사람에게 자동이며 누군가의 참여 없이 아주 자주 일정에 따라 발생합니다.
나는 명시적이고 명확하게 작성했습니다. 자동으로 밀리초 단위로 매일 수정합니다.
그리고 예, 전기톱에 쇠지렛대를 밀어 넣으면 날짜가 초 단위로 변경되는 순수한 WinAPI 함수( GetTickCount 란 무엇이며 QueryPerformanceCounter는 무엇입니까)에 의해 폭파될 것입니다. 일반적으로 귀하가 말하는 보호 장치가 없습니다. 문제로 손가락에서 빨려, 그리고 아마도 해결책.
WinAPI가 그렇습니다.
난 동의하지 않는다.
WinAPI는 GetMicrosecondCount와 달리 현지 시간 조정에 응답하지 않습니다.
난 동의하지 않는다.
WinAPI는 GetMicrosecondCount와 달리 현지 시간 조정에 응답하지 않습니다.
절대 시간이 아니라 프로그램 시작부터 델타를 표시하기 때문에:
GetMicrosecondCount() 함수는 MQL5 프로그램 시작 이후 경과된 마이크로초 수를 리턴합니다.
응용 프로그램 시작 시 카운터 값이 고정되어 있으므로 이 델타는 날짜 변경의 영향을 받습니다. 시간 종속 소프트웨어가 실행 중일 때 컴퓨터에서 날짜를 심각하게 변경하는 것은 일본 전기톱을 든 러시아 남성의 접근 방식과 난파선입니다. 농담으로 좋습니다.
"결국 배경 시간 보정기가 작동합니다"라는 정당화는 여기에 적합하지 않습니다. 보정은 하루에 밀리초이며 아무런 효과가 없습니다.
마이크로초 타이머는 시간의 시작부터 카운터가 아니라 짧은 기간의 정확한 측정을 위해 필요합니다.
난 동의하지 않는다.
WinAPI는 GetMicrosecondCount와 달리 현지 시간 조정에 응답하지 않습니다.
그러나 현재 버전에서 프로그램의 전체 작업을 망치는 GetMicrosecondCount의 실제 적용을 어떻게 보십니까? 실제 적용을 설명
예를 들어, Renat에서 설명한 옵션을 제외하고 C ++ 또는 여기에는 옵션이 표시되지 않습니다. mcs 단위의 정확도로 코드 실행 시간 측정
저것들. 솔직한 너의 고집이 이해가 되지 않아
카운터 값은 응용 프로그램 시작 시 고정되므로 이 델타는 날짜 변경의 영향을 받습니다. 시간 종속 소프트웨어가 실행 중일 때 컴퓨터에서 날짜를 심각하게 변경하는 것은 일본 전기 톱으로 러시아 남성의 접근과 방해 행위입니다. 농담으로 좋습니다.
나는 특히 애니메이션 gif에서 인터넷을 통한 시간 동기화를 보여주었습니다. 이 동기화는 기본적으로 모든 사람에게 자동이며 누군가의 참여 없이 아주 자주 일정에 따라 발생합니다.
그리고 이 동기화가 측정 중에 발생할 수 있다는 보장은 없습니다.
나는 GetMicrosecondCount()의 이 기능에 대해 이미 알고 있고 이 함수가 GetTickCount보다 훨씬 더 느리다는 것을 알고 있기 때문에 나 자신에 대해 걱정하지 않습니다.
그러나 이 스레드를 읽지 않고 이 기능에 대한 도움말을 아주 주의 깊게 읽는 다른 사람들은 실제 Expert Advisor의 논리에서 GetMicrosecondCount를 사용하면 문제에 부딪힐 수 있습니다. 테스트 중에는 모든 것이 정상이지만 예정된 시간 동기화 또는 겨울(여름) 시간으로 전환하는 시간에 실제 거래 중에 OH가 발생할 수 있습니다. 특히 시간이 감소하고 ulong 유형의 오버플로가 발생하면 OH가 발생할 수 있습니다.
그건 그렇고, 문서화되지 않은 이 새로운 정보는 동시에 여러 타이머의 작업을 구성하는 현재 생성 중인 다중 타이머 클래스의 논리를 크게 조정했습니다. 이 클래스의 작업에서 마이크로초 함수는 Might와 Main과 함께 사용되었습니다. 그러나 이제 속도를 높이는 것을 포함하여 15625μs의 정확도를 희생해야 한다는 것을 이해합니다.
페이버 턴 플리즈. 그는 비열하지 않습니다. 그는 단지 비열하지만 그는 착합니다.
젠장, 이제 나도 금지 :((
절대 시간이 아니라 프로그램 시작부터 델타를 표시하기 때문에:
응용 프로그램 시작 시 카운터 값이 고정되어 있으므로 이 델타는 날짜 변경의 영향을 받습니다. 시간 종속 소프트웨어가 실행 중일 때 컴퓨터에서 날짜를 심각하게 변경하는 것은 일본 전기 톱으로 러시아 남성의 접근과 방해 행위입니다. 농담으로 좋습니다.
"결국 배경 시간 보정기가 작동합니다"라는 정당화는 여기에 적합하지 않습니다. 보정은 하루에 밀리초이며 아무런 효과가 없습니다.
마이크로초 타이머는 시간의 시작부터 카운터가 아니라 짧은 기간의 정확한 측정을 위해 필요합니다.
저것들. 터미널을 주기적으로 다시 시작하는 것이 의미가 있습니까?
나는 특히 애니메이션 gif에서 인터넷을 통한 시간 동기화를 보여주었습니다. 기본적으로 이러한 동기화는 모든 사람에게 자동이며 누군가의 참여 없이 아주 자주 일정에 따라 발생합니다.
나는 명시적이고 명확하게 작성했습니다. 자동으로 밀리초 단위로 매일 수정합니다.
그리고 예, 전기톱에 쇠지렛대를 밀어 넣으면 날짜가 초 단위로 변경되는 순수한 WinAPI 함수( GetTickCount 란 무엇이며 QueryPerformanceCounter는 무엇입니까)에 의해 폭파될 것입니다. 일반적으로 귀하가 말하는 보호 장치가 없습니다. 문제로 손가락에서 빨려, 그리고 아마도 해결책.
맞습니다. WinAPI가 바로 이것이고 현실입니다.
저것들. 터미널을 주기적으로 다시 시작하는 것이 의미가 있습니까?
아니요.
내 주에는 캔들 닫는 시간 카운터가 5초씩 돌기 시작하는데, 프로그램에 문제가 있는 줄 알았다.
적절한 서비스와 시간을 다시 시작하고 동기화하는 데 도움이 됩니다.
얼마 전에 어머니의 배터리를 교체했습니다.
내 주에는 캔들 닫는 시간 카운터가 5초씩 돌기 시작하는데, 프로그램에 문제가 있는 줄 알았다.
적절한 서비스와 시간을 다시 시작하고 동기화하는 데 도움이 됩니다.
얼마 전에 어머니의 배터리를 교체했습니다.
매일 밤 (또는 더 자주) pool.ntp.org와 동기화하도록 일반 Windows 시간 서비스를 설정하면 일일 수정이 밀리초 단위로 이루어집니다.
구성되었지만 도움이되지 않습니다. 이유를 이해하지 못합니다. 사실, 내 서버는 ntp2.stratum2.ru입니다.