顾问的项目 - 页 6

新评论
 
Alexey Navoykov:

在文明世界中，清单是通过...

你为什么不在MQL中写一个文明的库，然后我们再谈。我们多年来一直听到这些呼声，当你深入了解时，你就会开始彻头彻尾的胡说八道。

MQ在CObject 的引用方面确实犯了一个错误。他们不应该在那里。而这些引用是在非常特殊的容器中使用的，如CList。但在没有错误的地方？你说，文明的语言？阅读Richter的评论，他对Object C#的看法以及它不应该包含哪些方法。所以因为Richter是对的，我们就应该拒绝使用C#？胡说八道。所以不要再在这里扎堆了，最后去你的程序性丛林吧。

 
George Merts:

嗯，是的，你不能把常量对象放在一个列表中。

然而，我经常使用CObject的功能，而没有一个批评者没有提供任何甚至类似于标准库对象的数组和列表。

"事情应该这样做 "是每个人的吆喝。但要提出一些建议，突然间，什么都没有了。

即使是那些真正提供不同软件解决方案的参与者--不提供CObject的替代品--更多的是根本不使用它，较少使用它的功能，不注意 "通过一个地方实施"。 而这意味着，实施是相当好的。

如果它是坏的，早就有人建议更换了。

通常情况下，当其他东西也都基于标准库时，就会使用本地CObject。特别是那些积极分享他们的源代码的人，倾向于统一，减少自我编写的代码和减少自己的库的数量，以使外部用户的生活更容易。但每个人都自己决定，他是为自己编码还是为别人的方便编码。

然而，我想许多人都在使用他们自己的解决方案（像我一样），他们只是认为没有必要把它们提供给别人。但总的来说，我认为如果有一些基于一些著名的库的标准会更好，比如MFC。这就是为什么我不太理解MQ，为什么他们不得不重新发明自己的车轮（除了非常有争议），而不是移植一个现成的解决方案。然而，对MQL语言本身也可以这么说。）

但原则上，我并没有强制拒绝CObject，我只是针对这句话提出了批评，即当有一个非常酷的MQ的CObject时，有人应该使用CMyCobject。）

 
Vasiliy Sokolov:

用MQL写一个文明的库，然后我们再谈。你已经嚷嚷了很多年，但当你开始着手处理时，你就开始彻头彻尾地骂人了。

嗯，我有自己的图书馆。那么你想谈什么呢？

我真的把CObject MQ中的引用弄乱了。他们一定不在那里。而这些引用是在非常特殊的容器中使用的，如CList。但在没有错误的地方？你说，文明的语言？阅读Richter的评论，他对Object C#的看法以及它不应该包含哪些方法。所以因为Richter是对的，我们就应该拒绝使用C#？胡说八道。所以不要再在这里扎堆了，最后去你的程序性丛林吧。

不要傲慢无礼，我不是在和你个人说话。

关于 "搞砸了链接"--嗯，是的，很有趣，在我已经画好了关于它的一切。虽然早些时候你在CObject 上简直是滴水不漏，说它是如此的伟大，甚至指针也不是默认在那里初始化的（至少你应该先研究一下你的语言的源代码）。总之，我看不出在这里对你进行诽谤有什么意义了。

 
George Merts:
但我同意，并不总是需要使用OOP。

比如，我有CDataProvider:pulic CDataProviderI类--数据提供者，它为Expert Advisor提供时间序列、指标、终端和环境数据。在专家顾问中，可以有许多TS--它们中的每一个都会从数据提供者那里接收到时间序列和指标的指针（每个TS不需要创建时间序列--数据提供者会提供必要的时间序列的指针，如果它们已经存在，并且只会创建尚未创建的时间序列）。

当你需要从数据提供者那里获得一个指标时--填写指标描述结构，然后从提供者那里请求一个指标，指向这个结构。

因此，数据提供者内部的每个指标应该能够识别其结构（数据提供者只 "知道 "结构的抽象基类）并根据它创建准备好的指标对象，这将由数据提供者创建。

但是，如果只是为了检查一个指标的新想法而开始这样一个项目，那是不合理的。因此，对于这样的新指标，一切都 "靠手"，没有任何OOP。 然而，如果我看到一个指标对专家顾问很有用--它是 "正确 "写的--有完整的OOP支持，并在一个数据提供者内创建。

对于许多在工作中使用相同指标的TS来说，这是一个很好的解决方案。

大约15年前，当我测试MT4中所有的指标是否适合在反向订单模式下进行交易时，我发现只有一个指标可以在每天的交易中获利。大多数指标都是基于内置指标，这就是为什么几乎所有的指标的交易结果都很低。 我认为任何交易者的首要任务是研究市场的预测准确性或模式的盈利能力。

与尊重。

最主要的是，他们不能混淆你的方向，让你看到他们想法的实现。 这整个马戏团的目的，是混淆和引导在错误的方向，远离利润。
 
Alexey Navoykov:

  1. 嗯，通常情况下，当其他东西也是基于标准库 的时候，就会使用常规的CObject。
  2. 特别是，那些积极分享其源代码的人通常会寻求统一。
  3. 减少自行编写的代码和
  4. 减少他们自己的图书馆的数量。
  5. 以使外部用户的生活更轻松。但每个人都自己决定，他是为自己编码还是为别人的方便编码。

好吧，你已经回答了你自己的问题，为什么你应该使用CObject，而不是自写的自行车。这是很有必要的，不仅是为了让别人的生活更轻松，而且主要是为了自己，因为 "统一"、"减少自写代码"、"减少自己的库的数量 "这些词--这是每个开发者应该努力的方向。这是程序员的圣杯。

当然，标准库已经过时了。现在的语言允许你做泛型，而接口也即将到来。但旧图书馆是有效的，它是一个很好的统一，正如他们所说的，最好的是好的敌人。既然没有所谓的完美和最好，你就必须使用好的。

关于 "乱七八糟的链接"--嗯，是的，这很有趣，在我已经写完了所有的内容。虽然早些时候你已经从字面上 "拉屎 "了CObject，说它是如此的伟大，甚至指针都没有在那里默认初始化（你至少应该从源语言开始研究）。总的来说，我不认为有必要对你进行诽谤。

在这里没有人会在你面前卑躬屈膝。相信我，你在这里向我们大家 "揭示 "的 "隐藏 "知识早已为许多人所知。我甚至不会争论链接初始化的问题。你知道你在形式上是正确的，所以你试图在同样的事情上摩擦我的鼻子：阅读数学，学习什么NULL，等等，等等。但你不必教我。你很冷静。你得到了这一切。那么你为什么要向我们扔珠子？去你的图书馆。看看它是否会变快0.5%。

 
Andrey Kisselyov:
分形和针形指标也经常被使用。对于许多在交易中使用相同指标的交易系统来说，这是一个很好的解决方案。但它们不适合测试，这就是为什么他们出于需要而这样做。 15年前，我在MT4中测试所有指标是否适合在反向仓位模式下交易，发现只有一个指标原来是每天都能盈利的。


不，你只需要把指标的本质搞清楚。指标不是现成的圣杯，而只是对价格运动的一些特殊性的方便表达。因此，我们不应该把它们当作 "最终的信号源"，而只是作为一个 "信号特征"，把它们作为一个复合体。而在这种情况下--大多数测试中开始需要许多指标。特别是ATR，例如，我已经在考虑在专家顾问的模板中把它标准化，因为我几乎到处都在使用它。MA MA也是很经常需要的指标。分形，针状指标...

 
George Merts:

...

但是，我同意，远非总是需要使用OOP。

比如，我有一个CDataProvider:pulic CDataProviderI类--一个数据提供者，它为专家提供时间序列、指标、终端和环境数据。在一个专家顾问中，可以有许多TS--它们中的每一个都将从数据提供者那里接收指向时间序列和指标的指针（每个TS不需要创建时间序列--数据提供者将提供指向必要的时间序列的指针，如果它们已经存在，并且将只创建尚未创建的时间序列）。

当你需要从数据提供者那里获得一个指标时--填写指标描述结构，然后从提供者那里请求一个指标，指向这个结构。

因此，数据提供者内部的每个指标应该能够识别其结构（数据提供者只 "知道 "结构的抽象基类）并根据它创建准备好的指标对象，这将由数据提供者创建。

但是，仅仅为了检查一个指标的新想法而启动这个项目是不合理的。因此，对于这样的新指标，一切都 "靠手"，没有任何OOP。然而，如果我看到一个指标对专家顾问很有用，它就会被 "正确 "地写出来--有完整的OOP支持，并在一个数据提供器内创建。

P.S.

顺便说一下，在指标和数据提供者的情况下，我们看到了虚拟化继承的优势。 我们有指标参数的基本接口 CIndicatorParametersI；这个接口的后代是必要指标的真正参数。在请求指标时，我们声明这些参数并向数据提供者传递一个指向抽象接口的指针。因此，数据提供者本身甚至不知道请求的是什么指标--它被定义在一个函数中，其中的指标是根据新类型创建的。而具体传递了什么参数--只有这个创建的指标知道，它从传递的对象中提取所需的参数。

诀窍在于，在数据提供方内部几乎所有的地方都有一个简单的基本参数类（或指标）--只有基本接口的最简单和最常见的功能对数据提供方可用。这简化了代码的修改（当需要时），并且不会产生 "篡改 "数据提供者的指标代码的诱惑。如果你想改变一个指标，只能在指标内部进行，数据提供者只是一个指标的存储，它最多只能创建一个新指标。

我认为你把它弄得太复杂了。日期提供者是MetaTrader本身。也就是说，并不真正需要日期提供者，它只需要一个处理数据的方便接口。例如，在我的Libera中，你只需要写出最后一栏的开盘价。

double open_price = WS.Open[0];

WS对象总是在那里，它总是在手边并在工作。它是如何做到这一点的，隐藏在幕后。这都是对数据的访问:)

s.o.p. OOP应该减少系统使用的复杂性，而不是增加它。如果你承认你必须为一个简单的检查而建造一个花园， 这意味着你的建筑与供应商有问题。也就是说，你编了一个你并不总是想用的东西。
 
George Merts:

不，你只需要把指标的本质搞清楚。指标不是现成的圣杯，而只是对价格运动的一些特殊性的方便表达。因此，我们不应该把它们当作 "最终的信号源"，而只是作为一个 "信号特征"，把它们作为一个综合体。而在这种情况下--大多数测试中开始需要许多指标。特别是ATR，例如，我已经在考虑在专家顾问的模板中把它标准化，因为我几乎到处都在使用它。MA MA也是很经常需要的指标。分形，针状指标...

我不认为ATP是一个指标，它显示了一定时期内市场的平均波动率，它不适合作为入场信号（它可以作为一个过滤器，仅此而已）。

我的意思是根据反转指标的信号在 "永远在市场上 "的模式下工作，再说，15年前，现在我对市场的看法已经略有改变。

与尊重。
 
Vasiliy Sokolov:

我认为你把它弄得比它需要的更复杂。数据提供者是MetaTrader本身。也就是说，你并不真的需要一个日期提供者，你只需要一个用户友好的界面来处理数据。例如，在我的Libera中，你只需要写出最后一个柱子的开盘价。

WS对象总是在那里，它总是在手边并在工作。它是如何做到这一点的，隐藏在幕后。这都是对数据的访问:)

s.w. OOP应该减少使用系统的复杂性，而不是增加它。而如果你自己承认，为了一个简单的检查，你必须建造一个菜园， 这意味着你的ISP架构有问题。也就是说，你编了一个你并不总是想用的东西。

你（姑且称为 "你"）的作品 "WS。Open[0]; "与我的条目 "m_tcMainContainer.Open(0) "差别甚微。

我怀疑在WS对象的初始化中一定有一些初步动作。

在我的案例中，我们应该调用 bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer)函数。

在专家顾问的每个部分（在输入的生成器中，在跟踪和退出的控制器中，即在可以执行交易行动的对象中），我都有 "时间序列容器 "对象--事实上，它是一个指向OHLCSTVtVr时间序列的指针，带有额外的服务选项。

在专家顾问中可以有许多不同符号和不同时间框架的容器。数据提供者的意识形态允许不重复它们。因为在现实中--所有的时间序列都储存在其中，而容器--只需指向必要的那些。

我看不出有什么不同--根据我的理解，WS（WareStore，可能）仍然是我的数据提供者。只是我的数据提供者也集中了其他的数据--指标、符号（CSymbolInfo对象）、终端（CTerminalInfo对象），其中也有图表的集合。在每次刷新中，时间序列被更新（根据需要）--这里的意识形态与标准库的意识形态接近。

如果我们认为MT4-5本身是数据提供者，而我们的类只用于提供访问--那么事实证明，根据您对开盘价的参考，我们必须为一个值调用CopyOpen()函数--这对我来说似乎是不合理的。


我也认为在程序的任何地方给予所有变量完全的全局访问权是非常不合理的，相反，我试图只访问那些结构和数据，这些结构和数据是在程序的每个地方需要的。其他的东西都必须是不能接触到的。数据提供者的意识形态使我能够控制这种访问。

 
Andrey Kisselyov:
我不认为它是一个指标，它显示了一定时期内市场的平均波动率，它不适合作为入场信号（它可以作为一个过滤器，仅此而已）。

我的意思是根据反转指标的信号在 "永远在市场上 "的模式下工作。我再次重申，15年前，现在我对市场的看法略有改变。

恭敬地说。

你说的 "ATR不算是一个指标 "是什么意思？

那它怎么会 "不适合作为入市信号呢？我是个傻瓜，我使用 "波动率分解 "条目只使用这个指标...？

我非常怀疑你对指标的本质有你自己的、特殊的理解......对我来说，指标是一个可以产生一些可变价值的对象，取决于时间。事实上，即使是普通的价格烛台图也是一个指标。但对你来说，它是另一种东西......因此，我们的理解是不同的。

1234567
新评论