Особенности языка mql5, тонкости и приёмы работы - страница 93
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Таков WinAPI.
Не соглашусь.
WinAPI не реагирует на корректировку локального времени в отличии от GetMicrosecondCount.
Не соглашусь.
WinAPI не реагирует на корректировку локального времени в отличии от GetMicrosecondCount.
Потому что у нас время показывается не абсолютное, а дельта от начала запуска программы:
Функция GetMicrosecondCount() возвращает количество микросекунд, прошедших с момента начала работы MQL5-программы.
Так как значение счетчика на старте приложения фиксируется, то на эту дельту влияет смена даты. Менять серьезно дату на компьютере, когда там работает софт, зависимый от времени - это вредительство и подход русских мужиков с японской бензопилой. Для анекдота сойдет.
Обоснование "ну ведь работает же фоновой корректор времени" тут не подходит - его коррекция миллисекунды в сутки и он не оказывает влияния.
Микросекундный таймер нужен для точного замера мелких периодов, а не для счетчиков от начала времен.
Не соглашусь.
WinAPI не реагирует на корректировку локального времени в отличии от GetMicrosecondCount.
а как вы видите практическое применение GetMicrosecondCount что оно вам портит всю работу программы в текущем варианте ? опишите практическое применение
я к примеру ни в С++ ни тут не вижу вариантов, кроме тех, что описал Ренат, т.е. замер времени исполнения кода с точность в mcs
т.е. я не понимаю вашего упорства если честно
Так как значение счетчика на старте приложения фиксируется, то на эту дельту влияет смена даты. Менять серьезно дату на компьютере, когда там работает софт, зависимый от времени - это вредительство и подход русских мужиков с японской бензопилой. Для анекдота сойдет.
Я специально на анимированной гифке показал синхронизацию времени по интернету. Такая синхронизация по умолчанию стоит у всех автоматически и происходит это по графику без участия кого-то и достаточно часто.
И нет гарантии что во время замера может произойти эта синхронизация.
За себя я не переживаю, так как уже знаю о такой особенности работы GetMicrosecondCount() и что эта функции более чем на порядок медленее GetTickCount.
Но другие, которые не прочитают этой ветки, но прочитают справку по этой функции даже очень внимательно, могут напороться на неприятности, если будут использовать GetMicrosecondCount в логике работы реального советника, т.к. в процессе тестирования будет все ОК, а во время реальной торговли в момент плановой синхронизации времени или перевода на зимнее(летнее) может произойти ОЙ, особенно если время уменьшится и произойдет переполнение типа ulong.
И кстати, данная новая для меня недокументированная информация внесла существенные коррективы в логику работы создаваемого сейчас класса мультитаймера, который организует работу нескольких таймеров одновременно. В работе этого класса вовсю использовалась микросекундная функция. Но теперь понимаю, что придется пожертвовать точностью в 15625 мкс, в том числе и для того, чтобы повысить его быстродействие.
Фабера вертите плиз. Он не злобный, он просто въедливый, но он хороший.
Блин, сейчас и меня забанят :((
Потому что у нас время показывается не абсолютное, а дельта от начала запуска программы:
Так как значение счетчика на старте приложения фиксируется, то на эту дельту влияет смена даты. Менять серьезно дату на компьютере, когда там работает софт, зависимый от времени - это вредительство и подход русских мужиков с японской бензопилой. Для анекдота сойдет.
Обоснование "ну ведь работает же фоновой корректор времени" тут не подходит - его коррекция миллисекунды в сутки и он не оказывает влияния.
Микросекундный таймер нужен для точного замера мелких периодов, а не для счетчиков от начала времен.
Т.е. есть смысл периодически перезагружать терминал?
Я специально на анимированной гифке показал синхронизацию времени по интернету. Такая синхронизация по умолчанию стоит у всех автоматически и происходит это по графику без участия кого-то и достаточно часто.
Я написал явно и четко - суточная коррекция на миллисекунды автоматически.
И да, вас точно также взорвет чистая WinAPI функция (что GetTickCount, что QueryPerformanceCounter), когда вы подсунете лом в бензопилу, поменяв дату даже на секунды. Вообще нет никакой защиты, о якобы наличии которой вы говорите. Высосанная из пальца как проблема, так и якобы решение.
Так что все верно - таков WinAPI и такова реальность.
Т.е. есть смысл периодически перезагружать терминал?
Нет.
У меня за неделю счетчик времени закрытия свечи начинает спешить секунд на 5, я подумал что тут дело в программе.
Помогает перезапуск и синхронизация времени с сервисом соответствующим.
Батарейку на матери не так давно менял.
У меня за неделю счетчик времени закрытия свечи начинает спешить секунд на 5, я подумал что тут дело в программе.
Помогает перезапуск и синхронизация времени с сервисом соответствующим.
Батарейку на матери не так давно менял.
Настройте штатный Time сервис Windows для синхронизации ежедневно ночью(или чаще) с pool.ntp.org и суточная коррекция будет в миллисекунды.
Настроено, но не помогает - не понимаю причину. Правда сервер у меня ntp2.stratum2.ru