'Ask' - function not defined Impulse.mqh 51 20
'Ask' - function not defined Impulse.mqh 51 28
'PendingOrders' - undeclared identifier Impulse.mqh 56 16
'GetOrder' - object pointer expected Impulse.mqh 58 44
'IsMain' - member function not defined Impulse.mqh 59 34
'Modify' - member function not defined Impulse.mqh 66 19
'Delete' - member function not defined Impulse.mqh 69 19
'Bid' - function not defined Impulse.mqh 85 20
'Bid' - function not defined Impulse.mqh 85 28
'PendingOrders' - undeclared identifier Impulse.mqh 90 16
'GetOrder' - object pointer expected Impulse.mqh 92 44
'IsMain' - member function not defined Impulse.mqh 93 34
'Modify' - member function not defined Impulse.mqh 100 19
'Delete' - member function not defined Impulse.mqh 103 19
'Bid' - function not defined Impulse.mqh 118 23
'Bid' - function not defined Impulse.mqh 118 31
'Bid' - function not defined Impulse.mqh 124 7
'Ask' - function not defined Impulse.mqh 136 23
'Ask' - function not defined Impulse.mqh 136 31
'Ask' - function not defined Impulse.mqh 142 7
20 error(s), 0 warning(s) 21 1
偏向 const 方法。我成为了一名 C# 程序员,但在 C# 中并不存在这种情况,因为修改器施加的限制并不起作用。
我天真地以为,这个修改器还能告诉编译器在编译时在哪里创建更优化的本地代码....。
我自己使用它是为了自我控制。
策略测试器 的主要时间都花在了基础架构的工作上(条形图滚动、交易环境模拟等),而专家顾问代码本身花费的时间要少得多。
另一方面,分析表明,CSTartegy 的主要资源密集型方法是 BuyInit、SellInit、BuySupport 和 SellSupport 方法,即 Expert Advisor 逻辑本身。所有其他绑定都以最佳方式成功编译到平面代码中,如果不使用,则直接剪切掉。这就是为什么高级 OOP 编程是合理的。
需要注意的是,如果智能交易系统或多或少比较复杂,有许多规则和繁重的基础结构,以最初的扁平化形式(没有函数和 OOP)进行编程将不可避免地导致程序员出错,其结果是,这样的智能交易系统的性能甚至会比使用 OOP 时更低。汇编程序的时代已经过去。编译器早已在某些优化领域打败了人类。
。
我天真地以为,这个修改器还能告诉编译器在编译过程中在哪里创建更优化的本地代码.....。
我自己也使用它进行自我控制。
我双手双脚都支持 OOP。只要它的背后没有隐藏拐杖式的解决方案,比如多符号 OnTick。开发人员正式认为这不是一个拐杖解决方案。
遗憾的是,在用户层面却无能为力。虽然 CStrtategy 中的 OnTick 是多值的,但它的多值性也是通过拐杖模拟出来的。只需在每个传入事件中请求另一个工具的 tick,如果它发生了变化,就会为该工具生成一个新的 OnTick 事件。顺便说一下,在 FORTS 上,CStrategy 通过 OnBookEvent 事件提供了真正的多货币 OnTick。不过,这也只是在测试工具中进行的模拟。
另一种方法是为 CStrategy 提供资源指示器。在启动时,CStrategy 会在必要的符号上启动该指标的实例,并从中接收新的 tick 到达事件。然后将其转换为 OnTick CStrategy。这是一个典型的拐杖,但整个实现过程都巧妙地隐藏在幕后,任何策略都能以统一的方式运行,而无需知道这些刻度是如何接收到的。
遗憾的是,在用户层面上对此无能为力。虽然 CStrtategy 中的 OnTick 是多币种的,但它的多币种性也是通过拐杖来模拟的。只需在每个传入事件中请求另一个工具的 tick,如果它发生了变化,就会为该工具生成一个新的 OnTick 事件。顺便说一下,在 FORTS 上,CStrategy 通过 OnBookEvent 事件提供了真正的多货币 OnTick。不过,这也只是在测试器中进行的模拟。
不幸的是,这种方法会错过 ticks。
另一种方法是为 CStrategy 提供资源指示器。在启动时,CStrategy 会在必要的符号上启动该指标的实例,并从中接收新刻度到达的事件。然后将其转换为 OnTick CStrategy。这是一个典型的拐杖变体,但整个实现过程被巧妙地隐藏在幕后,任何策略都能以统一的方式运行,而无需知道这些刻度是如何接收到的。
不幸的是,这种方法会漏掉 "勾子"。
是的,这种方法得到了开发人员的认可。但是,在我看来,如果考虑到优化测试人员的资源是如何用在其他平台最简单的任务上的,这种方法就显得非常蹩脚了。当然,OOP 巧妙地隐藏了这一弊端。我斜着看了一些非常有用的文章,我几乎读不下去了--也许我漏掉了什么,我对吊坠很感兴趣,但冲动中缺少很多数据,请指点一下......还是要我自己输入????
我斜着看了一些非常有用的文章,我几乎读不下去了--也许我漏掉了什么,我对吊坠很感兴趣,但冲动中缺少很多数据,请指点一下......还是要我自己输入????
如果您有不明白的地方,可以在本主题中提问。