巴解组织的间接费用 - 页 4 1234567 新评论 fxsaber 2017.07.06 18:07 #31 George Merts:我的经验表明，你确实需要这样做。 我大约在五年前走了这条路，那时是在MT4上。(不是因为我不知道OOP，而是因为我太懒了，懒得去理会接口和继承，尤其是当时MT4和MT5在MQL的实现上有很大的不同）。 这让我明白了它的谬误。 这不是 "智慧"，而是相当合理的限制，是一种 "傻瓜"。如果你总是记得数百个变量中的每一个负责什么--你就不需要封装了。我不记得了，我更喜欢在一个程序的每个区块中尽可能少的实体可用。 当MQL4出现OOP时--我开始将我所有的开发成果转化为基于接口的单一形式。 我仍然没有设法想出比MQL4-订单系统更方便的办法。如果你有一个例子，请给我看看。与MQL4相比，我所看到的所有交易API看起来都很可怕。他们也很笨拙。 Alexey Volchanskiy 2017.07.06 21:03 #32 fxsaber:我从来没有想出比MQL4订单系统更方便的东西。如果你有一个例子，请给我看看。与MQL4相比，我所见过的所有交易API都显得非常可怕。而且更重要的是，他们很笨拙。会有什么好处呢？每个参数都必须在一个单独的函数中画出来。更合理的做法是通过请求接收带有所有参数的结构，就像接收ticks一样。 Georgiy Merts 2017.07.07 05:07 #33 fxsaber:我从来没有想出比MQL4订单系统更方便的东西。如果你有一个例子，请给我看看。与MQL4相比，我所见过的所有交易API都显得非常可怕。而且更重要的是，他们很笨拙。你是什么意思？ 订单的本质是什么？是的，我同意，这是相当方便的。 但在我看来，仅仅是OOP在这个系统中的应用，就能带来最大的 "胜利"。假设我有相同的界面--同时给出由订单组成的MT4仓位和由MT5仓位组成的MT5仓位，并且不考虑对冲或净额结算条件。 在我看来，当我们有一个通过Select()函数获得的订单对象（或MT5头寸）的列表，我们处理订单的属性，而不是通过函数处理的"环境状态"（通过同一函数获得），这就更符合逻辑，更容易理解。 最有趣的是，如果我们需要同时跟踪几个订单--在这种情况下，程序化的方法不可避免地会导致一个 "伪对象"--我们必须创建一个订单信息数组，在进入OnTick()时应该被更新，并通过数组中的索引来处理订单数据，就像使用OOP-指针到订单对象。此外，在同时处理历史订单和活动订单时，OOP方法会给我们带来优势，因为历史订单界面是活动订单的继承者。而且，程序化的方法意味着历史订单和活动订单由不同的函数处理，这就更不方便了。 fxsaber 2017.07.07 05:49 #34 Alexey Volchanskiy: 有什么好处呢，每个参数都必须由一个单独的函数来拉动。这将是合乎逻辑的，就像ticks一样，在请求时获得带有所有参数的结构。Order.TakeProfit和OrderTakeProfit()条目是一样的。第一种只有存储对象的可能性，而第二种则是相关性。储存的需求很少被满足，而且不是在TS中。而在那里，创建结构是没有问题的。我自己也在想，为什么开发人员没有做订单结构的返回，而把每个字段单独通过一个函数留下（对于历史来说每次也是一张票）。一般来说，我不认为MQL4-API有什么真正的问题（它可能不仅在MT4/5中工作）。 fxsaber 2017.07.07 06:08 #35 George Merts:你是什么意思？ 订单交易的本质是什么？是的，我同意，相当方便。 但在我看来，仅仅是OOP在这个系统中的应用，就能带来最大的 "胜利"。假设我有相同的界面--同时给出由订单组成的MT4仓位和由MT5仓位组成的MT5仓位，而且不管是对冲还是净值。你有自己的包袱，对方有自己的包袱。问题是，是否有可能创建一个比MQL4更方便的包装器。 在我看来，当我们有一个使用Select()函数获得的订单对象（或MT5头寸）的列表，我们访问订单属性，而不是通过函数访问的"环境状态"（使用相同的函数获得），这更符合逻辑，更容易理解。最有趣的是，如果我们需要同时跟踪几个订单--在这种情况下，程序化方法不可避免地会导致 "伪对象 "方法--我们需要创建一个订单信息数组，在进入OnTick()时应该被更新，并通过数组中的索引来处理订单数据，其方式与我们处理订单对象的OOP指针相同。我在上一篇文章中写到了这一点。此外，当我们同时处理历史订单和活动订单时，OOP方法会给我们带来优势--因为历史订单的接口是与活动订单相继承的。 大多数函数是通用的。而且，程序性方法允许我们使用不同的函数来处理历史订单和活动订单，这就更不方便了。那么，在MQL4中，历史是由相同的函数处理的（OrdersHistoryTotal不算）。如果有一个代码例子，说明自己的交易API明显比MQL4-API好，那就更好了。我自己几乎到处都在使用OOP。而对于一些特定的任务，我做一些贸易包装。但它们并不通用，尽管在某些特定任务中使用起来非常方便。然而，我还是想比较一下通用的交易API。 Alexey Volchanskiy 2017.07.07 06:19 #36 fxsaber:我自己也在想，为什么开发人员没有把订单的返回变成一个结构，而是通过一个函数把每个字段单独留下（每次也需要一个票据来记录历史）。 原因是，在第600次构建之前，MT4中没有任何结构））。而新的MQL4出现在2013年初的某个地方。 fxsaber 2017.07.07 06:50 #37 Alexey Volchanskiy: Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.在MT5中，有结构，但仍然通过函数返回。 关于交易、自动交易系统和策略测试的论坛 OOP的开销 fxsaber, 2017.07.07 08:08 问题是不同的，是否有可能创建一个比MQL4更方便的包装器？ Alexey Volchanskiy 2017.07.07 08:27 #38 fxsaber:在MT5中，有结构，但无论如何要通过函数返回。也许他们决定不打破传统，但他们应该这样做。我理解如果数据是从经纪公司服务器上下载的，但它是本地的，它是即时取的，你可以立即填补这个结构 fxsaber 2017.07.07 08:49 #39 Alexey Volchanskiy: 他们可能决定不打破传统，尽管他们应该有如果数据是从DC服务器上下载的，我可以理解，但它们是本地的，它们是即时取的，你可以立即填补这个结构是的，在SELECT过程中，我们只是填充了一个隐藏结构的实例，其字段只能通过const（只读）函数来访问。可能，这是交易API内核中唯一有问题的决定。否则，我甚至不知道该抱怨什么。 Andrei01 2017.07.07 10:38 #40 fxsaber:是的，当使用SELECT时，它填补了一个隐藏结构的一个实例，其字段只能通过const（只读）函数访问。 这是为了限制对这个结构的访问。 1234567 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我的经验表明，你确实需要这样做。
我大约在五年前走了这条路，那时是在MT4上。(不是因为我不知道OOP，而是因为我太懒了，懒得去理会接口和继承，尤其是当时MT4和MT5在MQL的实现上有很大的不同）。 这让我明白了它的谬误。 这不是 "智慧"，而是相当合理的限制，是一种 "傻瓜"。如果你总是记得数百个变量中的每一个负责什么--你就不需要封装了。我不记得了，我更喜欢在一个程序的每个区块中尽可能少的实体可用。
当MQL4出现OOP时--我开始将我所有的开发成果转化为基于接口的单一形式。
我仍然没有设法想出比MQL4-订单系统更方便的办法。如果你有一个例子，请给我看看。
与MQL4相比，我所看到的所有交易API看起来都很可怕。他们也很笨拙。
我从来没有想出比MQL4订单系统更方便的东西。如果你有一个例子，请给我看看。
与MQL4相比，我所见过的所有交易API都显得非常可怕。而且更重要的是，他们很笨拙。
会有什么好处呢？每个参数都必须在一个单独的函数中画出来。更合理的做法是通过请求接收带有所有参数的结构，就像接收ticks一样。
我从来没有想出比MQL4订单系统更方便的东西。如果你有一个例子，请给我看看。
与MQL4相比，我所见过的所有交易API都显得非常可怕。而且更重要的是，他们很笨拙。
你是什么意思？
订单的本质是什么？是的，我同意，这是相当方便的。
但在我看来，仅仅是OOP在这个系统中的应用，就能带来最大的 "胜利"。假设我有相同的界面--同时给出由订单组成的MT4仓位和由MT5仓位组成的MT5仓位，并且不考虑对冲或净额结算条件。
在我看来，当我们有一个通过Select()函数获得的订单对象（或MT5头寸）的列表，我们处理订单的属性，而不是通过函数处理的"环境状态"（通过同一函数获得），这就更符合逻辑，更容易理解。
最有趣的是，如果我们需要同时跟踪几个订单--在这种情况下，程序化的方法不可避免地会导致一个 "伪对象"--我们必须创建一个订单信息数组，在进入OnTick()时应该被更新，并通过数组中的索引来处理订单数据，就像使用OOP-指针到订单对象。
此外，在同时处理历史订单和活动订单时，OOP方法会给我们带来优势，因为历史订单界面是活动订单的继承者。而且，程序化的方法意味着历史订单和活动订单由不同的函数处理，这就更不方便了。
有什么好处呢，每个参数都必须由一个单独的函数来拉动。这将是合乎逻辑的，就像ticks一样，在请求时获得带有所有参数的结构。
Order.TakeProfit和OrderTakeProfit()条目是一样的。第一种只有存储对象的可能性，而第二种则是相关性。储存的需求很少被满足，而且不是在TS中。而在那里，创建结构是没有问题的。
我自己也在想，为什么开发人员没有做订单结构的返回，而把每个字段单独通过一个函数留下（对于历史来说每次也是一张票）。
一般来说，我不认为MQL4-API有什么真正的问题（它可能不仅在MT4/5中工作）。
你是什么意思？
订单交易的本质是什么？是的，我同意，相当方便。
但在我看来，仅仅是OOP在这个系统中的应用，就能带来最大的 "胜利"。假设我有相同的界面--同时给出由订单组成的MT4仓位和由MT5仓位组成的MT5仓位，而且不管是对冲还是净值。
你有自己的包袱，对方有自己的包袱。问题是，是否有可能创建一个比MQL4更方便的包装器。
在我看来，当我们有一个使用Select()函数获得的订单对象（或MT5头寸）的列表，我们访问订单属性，而不是通过函数访问的"环境状态"（使用相同的函数获得），这更符合逻辑，更容易理解。
最有趣的是，如果我们需要同时跟踪几个订单--在这种情况下，程序化方法不可避免地会导致 "伪对象 "方法--我们需要创建一个订单信息数组，在进入OnTick()时应该被更新，并通过数组中的索引来处理订单数据，其方式与我们处理订单对象的OOP指针相同。
我在上一篇文章中写到了这一点。
此外，当我们同时处理历史订单和活动订单时，OOP方法会给我们带来优势--因为历史订单的接口是与活动订单相继承的。 大多数函数是通用的。而且，程序性方法允许我们使用不同的函数来处理历史订单和活动订单，这就更不方便了。
那么，在MQL4中，历史是由相同的函数处理的（OrdersHistoryTotal不算）。
如果有一个代码例子，说明自己的交易API明显比MQL4-API好，那就更好了。我自己几乎到处都在使用OOP。而对于一些特定的任务，我做一些贸易包装。但它们并不通用，尽管在某些特定任务中使用起来非常方便。然而，我还是想比较一下通用的交易API。
我自己也在想，为什么开发人员没有把订单的返回变成一个结构，而是通过一个函数把每个字段单独留下（每次也需要一个票据来记录历史）。
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
在MT5中，有结构，但仍然通过函数返回。
关于交易、自动交易系统和策略测试的论坛
OOP的开销
fxsaber, 2017.07.07 08:08
问题是不同的，是否有可能创建一个比MQL4更方便的包装器？
在MT5中，有结构，但无论如何要通过函数返回。
也许他们决定不打破传统，但他们应该这样做。
我理解如果数据是从经纪公司服务器上下载的，但它是本地的，它是即时取的，你可以立即填补这个结构
他们可能决定不打破传统，尽管他们应该有
如果数据是从DC服务器上下载的，我可以理解，但它们是本地的，它们是即时取的，你可以立即填补这个结构
是的，在SELECT过程中，我们只是填充了一个隐藏结构的实例，其字段只能通过const（只读）函数来访问。
可能，这是交易API内核中唯一有问题的决定。否则，我甚至不知道该抱怨什么。
是的，当使用SELECT时，它填补了一个隐藏结构的一个实例，其字段只能通过const（只读）函数访问。