许多人感兴趣的话题：MetaTrader 4和MQL4的新内容 - 即将发生的重大变化 - 页 9 12345678910111213141516...75 新评论 Vladislav Andruschenko 2013.07.25 12:45 #81 Urain:既然我们已经触及了市场，我想听听对一个问题的意见......根据MQL5的理念，指标应该计数，EA应该交易。但Market出售的是现成的解决方案，正如他们所说的，都是一体的。如何改进编译器，使指标作为资源存储在EA中？否则，我们必须将该指标的代码转移到专家顾问中，因为它没有合适的环境。同样，"从指标到指标 "的方案使得将代码转移到专家顾问中成为一个完整的事件。我同意。我认为现在为市场增加一个标签--FILES，在那里你可以放置套装、说明等，会很有用。我认为增加一个标签--FILES是很有用的，在那里你可以存储套装、指令等。 Rashid Umarov 2013.07.25 12:46 #82 Urain:我们能否完善编译器，将指标作为资源存储在EA中？否则，我们必须将指标代码转移到专家顾问中，在那里它没有合适的环境。同样，"从指标到指标 "的方案使得将代码移到专家顾问上成为一个完整的史诗。请看MetaTrader 5客户终端 在2012年11月24日的 构建7308.MQL5：增加了对EX5资源中存储指标的支持。同时，资源方面的指标将不能用自己的资源来工作。 Vladislav Andruschenko 2013.07.25 12:47 #83 Rosh:见2012年11月24 日发布的MetaTrader 5客户终端730版 新闻。 你说的mt4是什么意思？ Mykola Demko 2013.07.25 12:53 #84 Laryx:这正是我所做的。我已经写好了可以传递给专家顾问的自定义历史（而不是来自服务器的真实历史）的类。 但专家顾问不应该直接使用终端的功能来完全实现我的想法。说，同样的OrderSend()。它应该只通过一个 "包装器 "来工作，这个包装器的作用可以由标准库 很好地完成。我们编写派生类，把它们塞进Expert Advisor，瞧 - 它现在可以在历史数据上工作。 如果Expert Advisor直接使用终端的功能，它将无法使用历史数据。好吧，也许这是因为我长期从事MFC库的工作，我对它非常满意，而且我发现它有很多相似之处。我相信标准库的开发者对MFC也是相当熟悉的。标准库的主要优势是对OOP思想的良好支持，它允许向专家顾问传递一个自定义的历史，这样它就可以正常工作，而不需要进行任何修改。我可以问一下，你不喜欢标准库的什么吗（嗯，除了明显的缺点--"懒得学"）？这只是没有这样的缺点，我非常了解SB，这种知识让我了解到一切是多么的繁琐和低效。与其说是发送订单，不如说是为祖父启动了一个祖父，为萝卜启动了一个祖父。 但主要的缺点（据贸易部说）是完全没有对执行的控制。他们只是向服务器发送一个命令，然后让草生长。但他们用10种方式包装了Send，就像在所有场合一样，但案例却变成了100种。至于意识形态：继承两代以上的遗产是一个错误，再往后就会失去理解和灵活性。大多数类（你是对的）并没有被发明，它们只是从MFC重新发明的，但这并不是一个缺点，为什么要重新发明轮子。但我认为主要的缺点是他们不能依赖它）。我在有SB和没有SB的情况下都写了。没有它，你会变得更快、更透明。它的功能太多，所以在弯道上很迟钝。 Vasiliy Smirnov 2013.07.25 12:54 #85 例如，在Delphi中，有一个项目 的概念，这意味着联合编纂。而将程序分为3种类型，总的来说是有点可疑的，因为编译器在理论上可以自己决定程序的作用，但既然走到今天，指标只能靠强制交易，对于EA你需要在里面实现代码，那么我们只能希望开发者的心永远融化，他们会允许做项目）。 [删除] 2013.07.25 12:55 #86 Vladon:附议。我认为为市场增加一个FILES选项卡是很有用的，比如说，可以存储套装、说明等。虽然讨论标签允许这样做，但还是不一样。+++ Mykola Demko 2013.07.25 12:57 #87 Rosh:请参阅2012年11月24日 的MetaTrader 5客户终端build 730。太好了，我怎么会错过这个，啊，这是节前的建设。8.MQL5：增加了对EX5资源中存储指标的支持。同时，资源方面的指标将不能用自己的资源来工作。你帖子中的交叉点是否意味着他们已经可以了？ Georgiy Merts 2013.07.25 13:17 #88 Urain:恰恰没有这样的缺点，我非常了解SB，这些知识让我了解到一切是多么的繁琐和低效。谢谢你的全面回答。我对你的任何陈述都没有明确的反对意见。只是...一些观察...而不是发命令，祖父为祖父，祖父为萝卜。 但这也是赋予系统灵活性的原因，这也是让我们能够向EA发送自定义历史和服务器模拟的原因。如果订单直接通过OrderSend() 发送--我们将不得不这样写："外婆给外公，外公给外婆"......目前还不清楚哪个更好...但主要的缺点（据贸易部说）是完全没有执法控制。如果你把一个订单 "撞 "给了一个服务器，并且不屑一顾。但他们用10种方式包装了Send，就像在所有场合一样，但案例却变成了100种。我在这里没有足够的经验--我可能只是理论上的说法。我自己也分析过退货代码，但我的经验非常少。我同意，SB本身对执行的控制不够。至于意识形态：我认为继承两代以上的遗产是一个错误，进一步说，你会失去理解和灵活性。是的，的确，太深的继承对理解非常不利。但关于灵活性--我觉得很难同意。我有一堆4-5代继承的案例，似乎并没有引起任何问题。但是，我可以同意对我来说是这种情况，对其他人来说，这种继承的深度可能是一个主要障碍。但我认为主要的缺点是不可能依赖它，你在上面写了一些东西，它就会被重新加工 :)是的，我完全同意这一点。我在有SB和没有SB的情况下都写了。我用SB写作，但没有它，我变得更快、更透明。它的用途太广，所以在弯道上很笨拙。我喜欢SB，因为它能够创建一个TC模板，随后只将描述输入、维护和输出的对象类连接到它。如果没有SB，这样的意识形态恐怕会导致产生同样的，只有自己的SB。关于 "更快、更透明"--在我看来，当我们有任何TS作为一个整体对待时，这种意识形态是好的。然而，在我看来，这是一个严重的自动交易错误。TS应该只被看作是一组 "立方体"--一组输入生成器、输入TP-SL的决定因素、输入批次的决定因素、尾随控制器等等......。这种意识形态使我们能够非常迅速地获得数百种不同的TS变体，而我们只有一些 "更快、更透明 "的变体。 例如，在没有模板的情况下写了五个不同的TS--要写第六个，我们需要重新做，甚至使用这五个系统的部分内容。 在写完模板后--我们将把这五个系统的部分内容输入其中，结果我们将有多达五个输入生成器、输入过滤器、TP-SL决定因素等等。将它们结合起来，我们很容易得到一百个TS，我们可以从中选择最稳定和最有利的。因此，在我看来，SB的迟钝性确实是一把 "双刃剑"，它的应用与否应该在每个案例中单独决定。 Rashid Umarov 2013.07.25 13:33 #89 Urain:超级，我怎么会错过，啊啊啊是新年前的建设。你帖子中的划线是否意味着他们已经可以了？ 查看有关最新构建的新闻并亲自尝试 Igor Konyashin 2013.07.25 13:34 #90 Urain:太好了，我怎么会错过，啊，是新年前的建设。这里已经讨论过：https://www.mql5.com/ru/forum/3409#comment_408123 Обсуждение статьи "Использование ресурсов в MQL5" www.mql5.com Программы на MQL5 позволяют не только автоматизировать рутинные вычисления, но и создавать полноценную графическую оболочку. 12345678910111213141516...75 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
既然我们已经触及了市场，我想听听对一个问题的意见......
根据MQL5的理念，指标应该计数，EA应该交易。
但Market出售的是现成的解决方案，正如他们所说的，都是一体的。
如何改进编译器，使指标作为资源存储在EA中？
否则，我们必须将该指标的代码转移到专家顾问中，因为它没有合适的环境。同样，"从指标到指标 "的方案使得将代码转移到专家顾问中成为一个完整的事件。
我同意。
我认为现在为市场增加一个标签--FILES，在那里你可以放置套装、说明等，会很有用。
我认为增加一个标签--FILES是很有用的，在那里你可以存储套装、指令等。
我们能否完善编译器，将指标作为资源存储在EA中？
否则，我们必须将指标代码转移到专家顾问中，在那里它没有合适的环境。同样，"从指标到指标 "的方案使得将代码移到专家顾问上成为一个完整的史诗。
请看MetaTrader 5客户终端 在2012年11月24日的 构建730
8.MQL5：增加了对EX5资源中存储指标的支持。同时，资源方面的指标将不能用自己的资源来工作。
见2012年11月24 日发布的MetaTrader 5客户终端730版 新闻。
这正是我所做的。我已经写好了可以传递给专家顾问的自定义历史（而不是来自服务器的真实历史）的类。 但专家顾问不应该直接使用终端的功能来完全实现我的想法。说，同样的OrderSend()。它应该只通过一个 "包装器 "来工作，这个包装器的作用可以由标准库 很好地完成。我们编写派生类，把它们塞进Expert Advisor，瞧 - 它现在可以在历史数据上工作。 如果Expert Advisor直接使用终端的功能，它将无法使用历史数据。
好吧，也许这是因为我长期从事MFC库的工作，我对它非常满意，而且我发现它有很多相似之处。我相信标准库的开发者对MFC也是相当熟悉的。
标准库的主要优势是对OOP思想的良好支持，它允许向专家顾问传递一个自定义的历史，这样它就可以正常工作，而不需要进行任何修改。
我可以问一下，你不喜欢标准库的什么吗（嗯，除了明显的缺点--"懒得学"）？
这只是没有这样的缺点，我非常了解SB，这种知识让我了解到一切是多么的繁琐和低效。
与其说是发送订单，不如说是为祖父启动了一个祖父，为萝卜启动了一个祖父。
但主要的缺点（据贸易部说）是完全没有对执行的控制。他们只是向服务器发送一个命令，然后让草生长。但他们用10种方式包装了Send，就像在所有场合一样，但案例却变成了100种。
至于意识形态：继承两代以上的遗产是一个错误，再往后就会失去理解和灵活性。
大多数类（你是对的）并没有被发明，它们只是从MFC重新发明的，但这并不是一个缺点，为什么要重新发明轮子。
但我认为主要的缺点是他们不能依赖它）。
我在有SB和没有SB的情况下都写了。没有它，你会变得更快、更透明。它的功能太多，所以在弯道上很迟钝。
例如，在Delphi中，有一个项目 的概念，这意味着联合编纂。而将程序分为3种类型，总的来说是有点可疑的，因为编译器在理论上可以自己决定程序的作用，但既然走到今天，指标只能靠强制交易，对于EA你需要在里面实现代码，那么我们只能希望开发者的心永远融化，他们会允许做项目）。
附议。
我认为为市场增加一个FILES选项卡是很有用的，比如说，可以存储套装、说明等。
虽然讨论标签允许这样做，但还是不一样。
请参阅2012年11月24日 的MetaTrader 5客户终端build 730。
太好了，我怎么会错过这个，啊，这是节前的建设。
你帖子中的交叉点是否意味着他们已经可以了？
恰恰没有这样的缺点，我非常了解SB，这些知识让我了解到一切是多么的繁琐和低效。
谢谢你的全面回答。我对你的任何陈述都没有明确的反对意见。只是...一些观察...
而不是发命令，祖父为祖父，祖父为萝卜。
但这也是赋予系统灵活性的原因，这也是让我们能够向EA发送自定义历史和服务器模拟的原因。如果订单直接通过OrderSend() 发送--我们将不得不这样写："外婆给外公，外公给外婆"......目前还不清楚哪个更好...
但主要的缺点（据贸易部说）是完全没有执法控制。如果你把一个订单 "撞 "给了一个服务器，并且不屑一顾。但他们用10种方式包装了Send，就像在所有场合一样，但案例却变成了100种。
我在这里没有足够的经验--我可能只是理论上的说法。我自己也分析过退货代码，但我的经验非常少。我同意，SB本身对执行的控制不够。
至于意识形态：我认为继承两代以上的遗产是一个错误，进一步说，你会失去理解和灵活性。
是的，的确，太深的继承对理解非常不利。但关于灵活性--我觉得很难同意。我有一堆4-5代继承的案例，似乎并没有引起任何问题。但是，我可以同意对我来说是这种情况，对其他人来说，这种继承的深度可能是一个主要障碍。
但我认为主要的缺点是不可能依赖它，你在上面写了一些东西，它就会被重新加工 :)
是的，我完全同意这一点。
我在有SB和没有SB的情况下都写了。我用SB写作，但没有它，我变得更快、更透明。它的用途太广，所以在弯道上很笨拙。
我喜欢SB，因为它能够创建一个TC模板，随后只将描述输入、维护和输出的对象类连接到它。如果没有SB，这样的意识形态恐怕会导致产生同样的，只有自己的SB。
关于 "更快、更透明"--在我看来，当我们有任何TS作为一个整体对待时，这种意识形态是好的。然而，在我看来，这是一个严重的自动交易错误。TS应该只被看作是一组 "立方体"--一组输入生成器、输入TP-SL的决定因素、输入批次的决定因素、尾随控制器等等......。这种意识形态使我们能够非常迅速地获得数百种不同的TS变体，而我们只有一些 "更快、更透明 "的变体。
例如，在没有模板的情况下写了五个不同的TS--要写第六个，我们需要重新做，甚至使用这五个系统的部分内容。 在写完模板后--我们将把这五个系统的部分内容输入其中，结果我们将有多达五个输入生成器、输入过滤器、TP-SL决定因素等等。将它们结合起来，我们很容易得到一百个TS，我们可以从中选择最稳定和最有利的。
因此，在我看来，SB的迟钝性确实是一把 "双刃剑"，它的应用与否应该在每个案例中单独决定。
超级，我怎么会错过，啊啊啊是新年前的建设。
你帖子中的划线是否意味着他们已经可以了？
太好了，我怎么会错过，啊，是新年前的建设。
这里已经讨论过：https://www.mql5.com/ru/forum/3409#comment_408123