为什么MQL5数据库中的专家这么少？ - 页 9

[TheXpert]

simpleton:

'MyStruct' - 不支持正向声明

你去吧。你如何摆脱架构中的循环依赖？

不要告诉我它们不能存在于一个正常的架构中。唯一的（拐杖）方法是通过添加一堆不必要的基类来重新设计架构，这变成了一个真正的痛苦，因为缺乏多重继承，你拒绝了，正如我所理解的，不屑于实现菱形的依赖关系。

但你可以直接执行声明...

耶德尔金。

好吧，让我们看看相对于 "专业的系统程序员"，"无偏见的新手用户 "是否能够在MQL5中写出 "真正基本的东西"。

我哪里写了他们不能，亲爱的？是的，他们可以，但这将是一个粗糙和沉重的东西。

[Renat Fatkhullin]

TheXpert:

你去吧。如何摆脱架构中的周期性依赖？

由于复杂用例中的安全系统，我们还不允许向前描述。

我们有一种语言，在构建和运行时都有非常严格的控制。我们不能因为放松控制而得到潜在的泄漏代码。关键是这些描述可能在完全不同的库中，在这种情况下还没有严格的方法来控制使用。粗略地说，通过用其他方法塞进一个左撇子类来进行攻击是可能的（现在还做不到）。

已经有一个解决外部依赖和循环依赖的前向声明问题的方法，但我们将在启动64位终端（编译器、终端、编辑器和测试器）后实现它。我们今天已经准备了一个公开的32/64位版本--我们将在本周发布。

在你开始写一个直接对终端/执行环境安全的托管代码编译器之前（C#/Java与此无关，因为它对环境不安全），你很难理解一些开发者行为的原因。

[Yedelkin]

耶德尔金。

好吧，让我们看看，尽管有 "专业的系统程序员"，"没有偏见的新手用户 "能否在MQL5中写出 "真正基本的东西"。

TheXpert。

我哪里写了他们不能，亲爱的？是的，他们可以，但这将是一些粗制滥造的东西。

收到。由于 "一边倒的重物 "的概念指的是价值判断领域，所以在这个问题上你可以忘记客观性。这个话题对我来说已经结束了。

[Andrey Dik]

TheXpert:

你去吧。你如何摆脱架构中的循环依赖？

不要告诉我它们不能存在于一个正常的架构中。唯一的（拐杖）方法是通过添加一堆不必要的基类来重新设计架构，这变成了一个真正的痛苦，因为缺乏多重继承，你拒绝了，正如我所理解的，不屑于实现菱形的依赖关系。

但你可以直接执行声明...

我哪里写了他们不能，亲爱的？是的，他们可以，但这将是一个混乱的、沉重的事情。

恕我直言，我应该提到的是，从第五届论坛来看，埋怨和埋怨最多的是专家。当普通的业余爱好者在嚎叫和创造...你是专家，所以要做好自己的水平，有知识的人找机会，无知的人找理由......。对不起，如果有的话。

[Mykola Demko]

joo:
恕我直言，让我说，从第5个论坛来看，埋怨和抱怨最多的是专家。当普通的业余爱好者在嚎叫和创造...你是一个专家，所以要达到你的水平。对不起，如果有的话。

这是因为一切都是相对的。

那些从未坐过右舵日本车的人无法理解，怎么可能用左手换取变速箱。

而初学者并不关心，他不知道如何转移，不管是右还是左。

[Andrey Dik]

Urain:

这是因为一切都是相对的。

那些从未坐过右舵日本车的人无法理解，怎么可能用左手换取变速箱。

而初学者并不关心，他不能用右手或左手来转移它。

就这样，你把一切都搞得一团糟。:)

一个开惯了自动挡的外国车的人，在变速箱一团糟的沙河里动弹不得。但是，骑着 "经典 "的人，如果他愿意用 "日语 "驾驶，就会给任何用 "日语 "驾驶的人带来先机。我只是在说哲学，我的心情很好......注意我没有说 "初学者"，我说的是 "业余爱好者"。

[Sergey Gritsay]

joo:

就这样，你把一切都搞得一团糟。:)

任何一个开惯了自动挡的外国车的人，都无法在一个操蛋的变速箱的沙卡里行动。但是，如果他骑的是一辆 "古典 "汽车，那么他将会给任何驾驶 "日本 "汽车的职业选手带来先机。我只是在说哲学，我的心情很好......注意我没有说 "初学者"，我说的是 "业余爱好者"。

我自己是一名卡车司机，我已经开了10年的车，哪边是方向盘和变速杆并不重要，我开过很多车，它们都有自己的pernidal装置，所以我刚才说的是，要适应新车，只要开几英里就可以了，就像你一直在驾驶它一样。

[[删除]]

Renat:

已经有一个解决外部和循环依赖的前向声明问题的方法，但我们将在64位终端（编译器、终端、编辑器和测试器）推出后实施。我们今天已经准备了一个公开的32/64位版本--我们将在本周发布。

而在一个多月前宣布的版本中，这样一个重要的解决方案并没有出现。

雷纳特。

除非你开始自己编写一个托管代码编译器，直接强调终端/执行环境的安全（C#/Java与此无关，因为它对环境不安全），否则很难理解开发者某些行为的原因。

这里是对象构造器的解决方案--也是。使它们失去作用的原因不清楚。

他们不接受参数。我们现在应该模仿参数，使用全局变量来做吗？

没有任何机制可以报告一个对象没有被创建，因为在创建（初始化）一个子对象时发生了无法恢复的错误。我们可以为子对象中使用的所有类添加一个初始化函数，并从对象本身的相应类函数中调用子对象的初始化函数，这将提供返回错误代码的可能性。但是，首先，我们应该在对象创建后和它的 "下 "构造函数执行后明确地调用这样的函数（以及在用析构函数销毁对象前调用去初始化函数），其次，在修改主类时，例如，在添加一些子对象时，我们很容易忘记从主类初始化函数中调用添加的子对象的初始化函数，而且还要在适当的地方提供适当的顺序（同样适用于去初始化函数）。毕竟，实际上没有人从头开始一次性写出整件事情。因此，你得到的是半手工的、不安全的代码。

[Renat Fatkhullin]

simpleton:
而一个多月前宣布的版本并不包括这样一个重要的解决方案......。

是我们对语言负责，是我们对是否发布某一特定功能作出最终决定。所以不要因为时间问题而责怪我们。

没有任何机制可以报告对象没有被创建，因为在创建（初始化）其中一个子对象时发生了不可恢复的错误。我们可以为所有用于子对象的类添加一个初始化函数，并从对象本身的类的相应函数中调用子对象的初始化函数，这将提供返回错误代码的可能性。但是，首先，我们应该在对象创建后和它的 "下 "构造函数执行后明确地调用这样的函数（以及在用析构函数销毁对象前调用去初始化函数），其次，在修改主类时，例如，在添加一些子对象时，我们很容易忘记从主类初始化函数中调用添加的子对象的初始化函数，而且还要在适当的地方提供适当的顺序（同样也指去初始化函数）。毕竟，实际上没有人从头开始一次性写出整件事情。因此，你得到的是半手工的、不安全的代码。

你把它混为一谈，编造一些根本不属于你的问题，这就搅得人心惶惶。如果你如此害怕写作，那就放弃吧。

你知道什么阻碍了一个糟糕的舞者。

[TheXpert]

joo:

恕我直言，请允许我指出：从第五届论坛来看，埋怨和埋怨最多的是专家。

因此，有很多值得抱怨的地方。在第一个公开测试版发布后不久，我就开始编写一个交易系统。几乎立刻我就错过了正常的构造函数，然后我就完全放弃了，因为如果不用new操作符 明确地创建指针，就不可能得到指针。即使在那时，我也提出了导入类的可能性，鉴于程序及其结构（头文件和库文件或对象文件--在某些情况下只有必要的声明，在另一些情况下则是实现）的日益复杂，这是一个合乎逻辑的补充。

导入类和前向声明完全解决了代码放置问题。

拷贝构造器简化了构造器的问题。

导致我停下来的问题已经解决了。现在有一个GetPointer(this)结构。其他的事情（到目前为止）都可以在语言中解决，但它却毁了我的生活。

你是专家，要适合你的水平，因为有知识的人在寻找机会，无知的人在寻找理由。对不起，如果有的话。

所以我继续写下去。在这里谈话并不影响写代码。不需要为此道歉--我走得太远了。