mql5语言的特点、微妙之处以及技巧 - 页 92 1...858687888990919293949596979899...247 新评论 fxsaber 2018.07.31 08:40 #911 斯拉瓦。 在两次调用GetMicrosecondsCount用于测量微秒数的时间之间，本地计算机时间发生变化的概率是多少？不是零。 Renat Fatkhullin 2018.07.31 08:41 #912 TheXpert。 非常有建设性的讨论 )只是再有几个潦倒的人被永久删除，就这样了。 不再容忍那些急于封锁，试图把WinAPI函数的现实称为错误并指责我们的人。显然会有更多的建设性。 Konstantin Nikitin 2018.07.31 08:42 #913 fxsaber: 不是零。客户端/服务器交换时间损失的概率是多少，以毫秒计？可能比改变当地时间 的概率更大。 Konstantin 2018.07.31 09:36 #914 雷纳特-法特库林。只要再永久性地删除几个乱写乱画的人，就可以了。 不再容忍那些急于封锁的人，试图把现实说成是错误的，并指责我们。显然会有更多。稍微偏向主题的右边，在OnTimer()的方向））。 我不记得我在哪里读到的，有一个MQ的代表写道，有可能（对于那些有强烈欲望的人）将系统切换到1ms的延迟，然后，如果你使用EventSetMillisecondTimer(...)，OnTimer()也会工作，误差大约为1ms，但不是16ms。 如果我没有理解错的话，OnTimer()是用系统延迟来操作的，对吗？ ps.昨天给servcie-desk发了一个请求未处理，开始时间：2018.07.30 12:52，#2117844， 你能帮忙处理一下吗，从昨天开始就一直挂着)) Renat Fatkhullin 2018.07.31 09:59 #915 OnTimer与系统WinAPI定时器的错误一起工作，通过WinAPI函数GetTickCount 控制。这是一种非常快速和便宜的计时方法，对被测量的过程影响最小。这意味着它不会极大地影响最终结果。 对于整个操作系统来说，这个计时器的准确性可以得到提高，但代价是增加了CPU的消耗，以及大量程序开始的随机和大量诱发的影响。 更准确地测量时间少花点时间在滑梯上一些对普通错误有效的超时，会退化成彻底的坏行为。还有一些更酷的故障Windows系统的定时器问题已经有20多年历史了。但是，改变旧时代人的行为和准确性是很危险的。 这就是为什么新的、更精确的计时方法早已被引入。但它们是资源密集型的，用来完全替代旧计时器是不合理的。 我们用GetMicrosecondCount来实现更高精度的定时器。应该有意识地使用它，并理解它比GetTickCount花费更大。另外，在精确计量的情况下，调用GetMicrosecondCount的费用应该明确地考虑到。 滥用计时器和不保持基准的清洁，很容易欺骗自己和他人。 TheXpert 2018.07.31 10:05 #916 Renat Fatkhullin: 不再容忍那些急于求成的人，试图把WinAPI函数的现实称为错误并指责我们。显然会有更多的建设性。你可以简单地在帮助中写道：GetMicrosecondsCount依赖于本地 计算机时间，当它被修改时，可能工作不充分。GetTickCount则不然。 因此，如果你需要在我们和你的层面上解决这个问题，你可能应该在我们的层面上解决。 为什么要禁止？ Konstantin 2018.07.31 10:08 #917 雷纳特-法特库林。OnTimer与系统WinAPI定时器的错误一起工作，通过WinAPI函数GetTickCount 控制。这是一种非常快速和便宜的计时方法，对被测量的过程影响最小。这意味着它不会极大地影响最终结果。 对于整个操作系统来说，这个计时器的准确性可以得到提高，但代价是增加了CPU的消耗，以及大量程序开始的随机和大量诱发的影响。 更准确地测量时间少花点时间在滑梯上一些正常的超时工作会退化成彻底的错误行为和一些更酷的故障。Windows系统的定时器问题已有20多年历史。但是，改变旧时代人的行为和准确性是很危险的。 这就是为什么新的、更精确的计时方法早已被引入。但它们是资源密集型的，用来完全替代旧计时器是不合理的。 我们用GetMicrosecondsCount来实现更高精度的定时器。应该有意识地使用它，并理解它比GetTickCount花费更大。此外，在精确计量的情况下，应明确考虑调用GetMicrosecondsCount的成本。 滥用计时器和没有保持基准的清洁，很容易欺骗自己和他人。哎呀，这就是我在MQ的代表写了关于减少系统定时器时间后的想法 )) 所以我同意，没有必要在这个方向上改变什么。 顺便说一下，我想知道是否有像C#或至少像boost那样的反射 发展？ 例如，序列化/反序列化的实现会更方便。 Renat Fatkhullin 2018.07.31 10:15 #918 TheXpert: 你可以简单地在帮助中写上：GetMicrosecondsCount取决于本地计算机时间，当它被修改时可能无法充分工作。而GetTickCount并不依赖于它。 在帮助中写道：GetMicrosecondCount()函数返回微秒 数，自MQL5程序开始后经过 的时间。 这就是我明确说的：要测量微秒的数量。 关于微秒测量的问题也可以得到解决，尽管方式有些尴尬。 我们为什么要禁止？我们必须禁止。 首先，微秒计时器的时间测量没有问题。第二--有些人迫不及待地想找一个借口来发飙，然后坚持到最后。 再一次--规则已经改变。 不再接受任何侮辱或 "你必须"。我们将毫无预警地进行扫荡。 TheXpert 2018.07.31 10:46 #919 雷纳特-法特库林。 在帮助中是这样说的：GetMicrosecondCount()函数返回自MQL5程序开始以来所经过的微秒 数。而它是为GetTickCount函数 写的。 GetTickCount()函数返回自系统启动以来所经过的毫秒数。 这两个短语几乎相同，但一个函数取决于当地时间，另一个则不取决于，我们应该如何猜测？ Renat Fatkhullin 2018.07.31 10:59 #920 TheXpert。而它是为GetTickCount函数 写的。 这些短语几乎是相同的，但一个函数取决于当地时间，另一个则不取决于。我们怎么能猜到呢？这就是WinAPI。 提醒大家注意明确或隐含地使用 "应该 "短语。使用 "元引号必须 "而不是 "请考虑"，现在是不可接受的。 1...858687888990919293949596979899...247 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
在两次调用GetMicrosecondsCount用于测量微秒数的时间之间，本地计算机时间发生变化的概率是多少？
不是零。
非常有建设性的讨论 )
只是再有几个潦倒的人被永久删除，就这样了。
不再容忍那些急于封锁，试图把WinAPI函数的现实称为错误并指责我们的人。显然会有更多的建设性。
不是零。
客户端/服务器交换时间损失的概率是多少，以毫秒计？可能比改变当地时间 的概率更大。
只要再永久性地删除几个乱写乱画的人，就可以了。
不再容忍那些急于封锁的人，试图把现实说成是错误的，并指责我们。显然会有更多。
稍微偏向主题的右边，在OnTimer()的方向））。
我不记得我在哪里读到的，有一个MQ的代表写道，有可能（对于那些有强烈欲望的人）将系统切换到1ms的延迟，然后，如果你使用EventSetMillisecondTimer(...)，OnTimer()也会工作，误差大约为1ms，但不是16ms。
如果我没有理解错的话，OnTimer()是用系统延迟来操作的，对吗？
ps.昨天给servcie-desk发了一个请求未处理，开始时间：2018.07.30 12:52，#2117844， 你能帮忙处理一下吗，从昨天开始就一直挂着))OnTimer与系统WinAPI定时器的错误一起工作，通过WinAPI函数GetTickCount 控制。这是一种非常快速和便宜的计时方法，对被测量的过程影响最小。这意味着它不会极大地影响最终结果。
对于整个操作系统来说，这个计时器的准确性可以得到提高，但代价是增加了CPU的消耗，以及大量程序开始的随机和大量诱发的影响。
Windows系统的定时器问题已经有20多年历史了。但是，改变旧时代人的行为和准确性是很危险的。
这就是为什么新的、更精确的计时方法早已被引入。但它们是资源密集型的，用来完全替代旧计时器是不合理的。
我们用GetMicrosecondCount来实现更高精度的定时器。应该有意识地使用它，并理解它比GetTickCount花费更大。另外，在精确计量的情况下，调用GetMicrosecondCount的费用应该明确地考虑到。
滥用计时器和不保持基准的清洁，很容易欺骗自己和他人。
不再容忍那些急于求成的人，试图把WinAPI函数的现实称为错误并指责我们。显然会有更多的建设性。
你可以简单地在帮助中写道：GetMicrosecondsCount依赖于本地 计算机时间，当它被修改时，可能工作不充分。GetTickCount则不然。
因此，如果你需要在我们和你的层面上解决这个问题，你可能应该在我们的层面上解决。
为什么要禁止？
OnTimer与系统WinAPI定时器的错误一起工作，通过WinAPI函数GetTickCount 控制。这是一种非常快速和便宜的计时方法，对被测量的过程影响最小。这意味着它不会极大地影响最终结果。
对于整个操作系统来说，这个计时器的准确性可以得到提高，但代价是增加了CPU的消耗，以及大量程序开始的随机和大量诱发的影响。
Windows系统的定时器问题已有20多年历史。但是，改变旧时代人的行为和准确性是很危险的。
这就是为什么新的、更精确的计时方法早已被引入。但它们是资源密集型的，用来完全替代旧计时器是不合理的。
我们用GetMicrosecondsCount来实现更高精度的定时器。应该有意识地使用它，并理解它比GetTickCount花费更大。此外，在精确计量的情况下，应明确考虑调用GetMicrosecondsCount的成本。
滥用计时器和没有保持基准的清洁，很容易欺骗自己和他人。
哎呀，这就是我在MQ的代表写了关于减少系统定时器时间后的想法 ))
所以我同意，没有必要在这个方向上改变什么。
顺便说一下，我想知道是否有像C#或至少像boost那样的反射 发展？ 例如，序列化/反序列化的实现会更方便。
你可以简单地在帮助中写上：GetMicrosecondsCount取决于本地计算机时间，当它被修改时可能无法充分工作。而GetTickCount并不依赖于它。
在帮助中写道：GetMicrosecondCount()函数返回微秒 数，自MQL5程序开始后经过 的时间。
这就是我明确说的：要测量微秒的数量。
关于微秒测量的问题也可以得到解决，尽管方式有些尴尬。
我们为什么要禁止？
我们必须禁止。
首先，微秒计时器的时间测量没有问题。第二--有些人迫不及待地想找一个借口来发飙，然后坚持到最后。
再一次--规则已经改变。
不再接受任何侮辱或 "你必须"。我们将毫无预警地进行扫荡。
在帮助中是这样说的：GetMicrosecondCount()函数返回自MQL5程序开始以来所经过的微秒 数。
而它是为GetTickCount函数 写的。
GetTickCount()函数返回自系统启动以来所经过的毫秒数。
这两个短语几乎相同，但一个函数取决于当地时间，另一个则不取决于，我们应该如何猜测？
而它是为GetTickCount函数 写的。
这些短语几乎是相同的，但一个函数取决于当地时间，另一个则不取决于。我们怎么能猜到呢？
这就是WinAPI。
提醒大家注意明确或隐含地使用 "应该 "短语。使用 "元引号必须 "而不是 "请考虑"，现在是不可接受的。