Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
雷纳特，零--非常感谢你对这个话题的关注和你的建设性的回应!
下一步。
1.关于x64
Renat:
更正确的选择是升级到x64。
...
当然，如果有人要在市场扫描模式下调用数百个指标而不卸载，他们应该直接使用64位版本+安装额外内存。
此刻坐在X32上做大量的测试，这很奇怪。任何像样的x64电脑，16GB内存（不对显卡和显示器狂热），15000卢布就可以买到。
切换到x64是正确的行动方案。但是。一个并不排除另一个。即使是我的16G（我有），我也不想把它们挥霍在一些不必要的数据上。我还有其他要并行工作的东西--MSVS、Matlab等，我也想在它们上面计算大量的任务。我很高兴你能理解这一点，并愿意寻找省钱的方法。
2.关于历史的一个固定起点。
雷纳特。
我们自己也想减少资源消耗。也许解决方案可以是一些函数IndicatorMaxDepth(uint len)，它将只作用 于该EA中创建的指标。
但问题是，在测试过程中，累积模式下的指标缓冲区将与历史一起增长，而且没有保存。
完全（几乎）同意。免责声明：在许多情况下，优化是在上一个故事的一小块上进行的。在这种情况下，节省的费用可能是相当可观的。不过，我还是认为这个方案相对可行--特别是如果你有一个好的工作或对实施的估计。 例如，对我来说，这个方案似乎不是很成熟--很多劳动，而且结果不是很激进。一半的解决方案。
3.这里有一个想法!:
雷纳特。
在rltime中修剪指标的历史，同时保持设定的深度 ， 充满了美丽的故障，将直接击倒 计算/习惯于图表和指标缓冲区的条形同步的 程序员。
不! 如果图表条的行为方式相同--同步 的话，就不会有什么问题。换句话说--如果环形缓冲区（即使大小不同） 始终(强行）使用AsSeries标志--预计不会给用户 带来大量麻烦。
// 在这种情况下，使所有呈现给用户的历史缓冲区成为指标（即循环，AsSeries=true）是很方便的。
在这个变体中。
(1)有一个指标和价格数组的内部表示（在你这边）：从左到右的索引（AsSeries==false），大小与用户无关，而且确实"禁止进入"。
而（2）有一个用户方面--所有的缓冲区都是圆形的（在实现中，用户看到的是一个虚拟的线性数组），索引是从右到左（AsSeries==true），大小由用户设定。
这里用户的屋顶是什么？ 没有。超出范围时--标准响应 阵列超出范围。
只有你有困难（说实话，不小的困难）。 但是！考虑到计划的普遍性--你只需要紧张一次。并在测试版调试时将所有 "漂亮的小毛病 "扼杀在摇篮里。 之后--普遍的幸福和非常经济的 建设。
我们将对指示器缓存进行修改，现在使用最大效率的原则来反对节省内存的原则。被拒绝的指标将被立即卸载，而不是像现在这样在内存中保留一段时间。这将使我们有可能通过IndicatorRelease直接卸载的方式连续调用数百个指标。
3.亚兹尔来了!:
不! 它不会--如果图表栏的行为方式相同--同步进行。换言之--如果环形缓冲区（即使大小不同） 始终(强行）使用AsSeries标志--对用户来说，大规模的麻烦是不可预期的。
// 在这种情况下，使提供给用户的所有历史缓冲区具有指示性（即循环，AsSeries=true）是很方便的。
在这个变体中。
(1)有一个指标和价格数组的内部表示（在你这边）：从左到右的索引（AsSeries==false），大小与用户无关，而且确实"禁止进入"。
而（2）有一个用户方面--所有的缓冲区都是圆形的（在实现上。用户看到的是一个虚拟的线性数组），索引是从右到左（AsSeries==true），大小由用户设置。
这里用户的屋顶是什么？ 没有。当用户超出范围时--标准反应阵列超出范围。
只有你有困难（说实话，不小的困难）。 但是！考虑到计划的普遍性--你只需要紧张一次。而所有的 "漂亮的小毛病 "都必须在测试版调试期间扼杀在萌芽状态。 之后，每个人都很高兴，建设也非常经济 。
好主意，我很赞成。但它并没有取消环形方案的实施，只是很好地补充了它。让我描述一下测试条件。
由于指标的自动下调，我们
我将描述测试的条件。
由于指标的自动下调，我们。
1.
是的，它是可以容忍的。没有人禁止通过安装一个巨大的MaxBar来浪费内存，这几乎不会引起大众的不满，相反，经济将非常有吸引力。
// 但是，由于跳杠，指标出现了故障。这就是不满情绪的合理性所在!
// 所以你甚至容忍了......。:)嗯，我们必须...:(
2.
这恰恰是不对的，也是不对的！循环计划恰恰导致了在历史班次上复制的巨大节省。实际上，当移位一个柱子（N个柱子）时，我们必须准确地复制一个值（N个值）。索引虚拟化的（用户）成本可以忽略不计。事实上，它们在压力测试中甚至很难被发现（ 处理器在一个时钟周期内计算除法的剩余部分+在历史上每次移位时转移虚拟缓冲区的起点需要另外几个时钟周期）。因此，几乎 没有速度损失。不可能发现这种减速，它是如此之小。而在节省大量内存的背景下，这些损失与收益是不可比拟的。
3.
Ehhh, a face...
出于某种原因，有那么多关于指标在无限条上窒息的舞蹈和叫喊，但没有一个字是关于跳舞的图形对象。试着在无限期（例如在MN1）上建立超级大的Andrews'Pitchfork，然后在终端设置 中限制条数，转到低时间段并倒退到锚点。其中一些将与极值有巨大的时间差（这是当所有三个点的干草叉完全位于真正的M1条 的区域，而没有超出更高时间段的假条的边界！）。这又是为什么呢？显然，因为我们没有足够的M1 的历史数据来计算一些自动结合点的准确M1值。但历史数据与此有什么关系？好吧，也许他们已经足够了，但橱窗里展示的酒吧却没有，因此才有了这些转变。也就是说，有些点 "并不真正知道自己在哪里"。
我希望有人能自己检查一下，也许只有我一个人有这样的麻烦......。
我注意到一个奇怪的现象!
在形成一个新条形 的时刻，如果你读到以前条形的开盘和收盘值（例如10个以前的条形），然后5秒钟后再次得到它们，那么其中一些值是不同的，然后如果你在一个新条形形成时得到它们，那么一切都很好，但在最初的几秒钟，由于某些原因，这些值是不同的。
我希望我解释得很清楚。
你能告诉我，在从一个新的条形图开始读取开盘和收盘的数值之前，是否应该有一个超过5秒的延迟？
下面是一个操作的例子。
上图是延迟后正确触发的，下图是在一个新的条形图后立即触发的，有一个错误，右边是第六行的基准值。
也许问题是不同步的，一个新的酒吧 最好能被所有正在使用的工具所追踪。
是的，事实证明你是对的，谢谢你!
同样，歌剧也是如此。