Mt4结束支持。 - 页 29

 
Реter Konow:

主要的缺点:OOP迫使你走上将代码分割成许多函数的道路。

人类更容易接受碎片化的代码,但碎片化是任何机制所不允许的。

好吧,但缺点是什么呢?

这是最主要的优势!正是因为它更容易让人察觉到零散的代码。

计算机必须适应人类,而不是人类适应计算机。

 
George Merts:

这是正确的,但有什么坏处呢?

这是主要的优势!正是因为它更容易让人察觉到碎片化的代码。

计算机应该适应人,而不是人适应计算机。

唉,开发者首先应该考虑的是他的机制的效率,而不是他的舒适度))。

否则,该机制将 "跛行"。

开发者应该适应计算机。

 
Реter Konow:

如果报价来自同一个服务器,那么哪种工具就没有区别。毕竟,每个仪器上的小节是同时打开的。

如果引文的来源是在世界不同的地方,那就不同了。对于分钟来说,这并不重要,但在更高的时间范围内可能会有问题。也许需要对时间函数进行更详细的研究,需要进行准确的时间校正。但这是这个解决方案发展的下一个阶段...

你需要为这个功能做一个校准...

起初我想把没有我写的东西都看一遍,万一已经有了问答,但我怕以后很难找到需要引用的帖子。

现在只有一个问题:众所周知,在新的时间区间的第一个刻度线之前,不会出现一个新的柱状物。因此,如果按毫秒计算应该有一个柱子,但它不存在,你可以从错误的柱子上获得指标读数。

我希望能找到第二个问题的答案,这是由Artem提出的。

 
Alexey Viktorov:

起初我想把没有我写的东西都读一遍,以防已经有了问答,但我怕很难找到需要引用的帖子。

到目前为止只有一个问题:众所周知,在新的时间区间的第一个刻度线之前,不会出现一个新的条形图。因此,如果按毫秒计算应该有一个柱子,但却没有,我们可以从错误的柱子中获得指标值。

我希望能找到第二个问题的答案,这是由Artem提出的。

是的,我们昨天讨论过这个问题。

我曾经与另一个平台打交道,那里的条形图是按时间形成的,与报价的到来无关(看看TWS)。

有人告诉我,MT的情况并非如此。

我将增加一个报价到达检查,以确认新的酒吧出现的事件。

 
Реter Konow:

我已经回答过了,无论报价是否到达,酒吧都会开放。如果没有报价,新条形图的价格将是前一条形图的收盘价。无论报价是否到达,新条形的事实将被固定下来,由计数器本身决定,它在一个计时器上运行。

具体的时间框架并不重要,因为它只是一个达到其值的计数器,并设置该时间框架的新条的事件。这只是一种与不同时间段的新条形图的出现同步的方法。同步。

仪器也不重要。如果报价来自一个服务器,这意味着它们有相同的新条出现时间。因此,只要这些仪器来自全球的一个点,哪种仪器并不重要。


我会完成我所说的,然后做其他事情。一点点的好东西)。

而如何解释周五的收盘价,即任何时期的前一根柱子等于1.20333,而周一任何时期的开盘价等于1.20142?

当然这是一个经纪人的报价,其他的可能有点不同,但都是有区别的。

 
Alexey Viktorov:

而你如何解释周五的收盘价,即任何时期的前一根柱子是1.20333,周一任何时期的开盘价也是1.20142?

这当然是一个经纪人的报价,其他的可能有点不同,但他们都有差异。

这是用差距来解释的。它发生在会议开幕时。

我不是交易方面的专家,所以不要对我的意见进行过于严厉的评判)。


而我对外汇市场上发生的事情了解得更少)。

 
Реter Konow:

唉,设计师必须首先考虑他的机制的效率,而不是他的舒适度)。

否则,该机制将 "跛行"。

开发者必须适应计算机。

没有。

让电脑适应我。我有足够的其他问题。开发者只能在计算机无法处理任务的地方进行调整,例如,在缺乏性能或内存的瓶颈处。然后,是的,就轮到开发商来调整了。但到目前为止,我还没有遇到过任何地方,OOP会给计算机带来如此大的额外负荷,以至于必须以某种方式减少它。

 
Nikolai Semko:

类似这样的东西(MQL5的代码)。

但我重申--我是一个OOP的支持者。
这只是一个非常不成功的例子,说明程序化编程中不可能做到 的事情。

当我开始做这个的时候,我并不打算表明任何事情都是可能/不可能做到的,只是在将来写自己的代码时更方便使用。

但结果是,正如V.S.所说,我想要最好的,但结果还是一样。

 
George Merts:

哦,不。

是电脑在为我调整。我有足够的其他问题。开发者只能调整计算机 "无法处理 "的地方,例如在 "瓶颈",即性能或内存不足的地方。然后,是的,就轮到开发商来调整了。但到目前为止,我还没有遇到过任何地方,OOP给计算机提供了如此显著的额外负载,以至于必须以某种方式减少它。

计算机上的负载是由开发人员对其机制的一致性问题的粗心态度造成的。渴望节约能源以改善系统。以减轻他们的工作为名,不合理地浪费计算机资源。

只要计算机成功地应对了低效编写的代码,开发者就会继续 "寄生 "在处理能力上。这是一条死胡同。

迟早,无效的机制会停止发展,被更好的对应机制所取代。

人的时间和努力将被浪费,他的聪明才智最终将落入垃圾箱。

在竞争激烈的世界中,这种风险一直存在。

当我们设计机器时,我们应该首先考虑它们的性能,其次才考虑工作时间的舒适性和便利性)。

 
Реter Konow:

由于开发者对其机制的连贯性采取了疏忽的态度,这个负担就落在了计算机上。渴望在改进系统上节省精力。以使其工作更容易为名,不合理地消耗计算机资源。

只要计算机成功地应对了低效编写的代码,开发者就会继续 "寄生 "在处理能力上。这是一条死胡同。

迟早,无效的机制会停止发展,被更好的对应机制所取代。

人的时间和努力将被浪费掉,他的聪明才智将落入垃圾箱。

在竞争激烈的世界中,这种风险一直存在。

在开发机制时,我们首先应考虑其性能,其次应考虑我们工作时间的舒适性和便利性。)


这就是所谓的写 完程序 之前,不可能准确地指出这种片段。这就是为什么你应该首先写出能正确工作的(可被任何其他开发者阅读的)代码,然后才对其进行优化,如果那里有什么需要优化的话。