众包的GUI。公开测试。 - 页 48

新评论
 

彼得，你想怎么对待我都可以，这是你的权利，但要听从一个稍有经验的同志的建议。

#include <GUI_DRIVE.mqh>
#include "..\Files\CORES.mqh"
#include "..\Files\Internal_API.mqh"

GUI_DRIVE.mqh 文件在代码中被首先连接。 在它之前没有任何东西被宣布。

如果你编译它，你会得到缺少G_CORE的错误，这是合乎逻辑的，因为数组没有在这个文件中声明。

结论？嗯，结论很简单：数组必须在这个文件中声明。最后，是这个文件在操作这个数组，因为这个文件是 "引擎"!因此，根据使用环境，其中的数组本身的声明是正确的。

下一个文件，CORES.mqh ，用表单元素的描述填充阵列。

当然，当用这些文件编译EA本身时，如果数组是在第一个文件中声明的，就不会出现编译问题，因为当你编译第二个文件时，数组已经在程序的上下文中可见。

但我们要说的是，每个文件都应该无错误地编译。由于第二个文件将G_CORE数组填满了元素，如果数组 没有被声明，我们在编译这个文件时很自然地会遇到一个错误。

而在这里，正如亚历山大所说，我们使用的是一个存根。

皮奥特，你是辩护人的忠实粉丝，所以你会知道发生了什么事。

在文件GUI_DRIVE中，你声明了一个全局的内核元素数组G_CORE，之后文件的编译应该没有错误。

然后在这个文件中你添加一个定义。

#define __DRIVE__

转到Cores文件。在声明一个数组之前，请使用编译预处理程序。

#ifndef __DRIVE__
int G_CORE[][prop_limit];
#endif

然后你就把数组填满。当然，你必须改变一下填充数组的方式，以做到不需要声明。

我想你得到了要点：如果CORES文件被编译，__DRIVE__ 默认值就会消失，数组声明代码被编译，一切就 会正常。

如果该文件作为EA的一部分被编译，那么在编译完第一个文件后，Define被声明了，而在第二个文件中，数组没有被声明，因为编译器 "切割 "了这一段代码。

我希望我已经说得很清楚了。

我再重复一遍：每个文件都必须无错误地编译。如果你有依赖关系，你需要适当提供它们的位置，并根据需要添加重新编译处理器。

当你把每个文件都编译得没有错误时，你就会对整个系统的完整性更有信心。

另外，别忘了在每个文件中添加一个属性。

#property strict

这个属性对代码进行了更严格的检查。

 
这没有什么实际意义。如果每个文件的编译都没有错误，不管整个装配的完整性如何，用户很容易错过其中一个文件的连接。这很容易让人忘记。

总之，它是如此微不足道，我不会在上面浪费时间。这完全是一派胡言。这是一个无稽之谈。
 
是的，你可以通过操纵预处理程序使每个文件单独编译而不出错。

但这正是错误所在。它们是一个整体的一部分，不应该 "描绘 "出独立于其他部分的形象。而事实上，用户可能会决定不需要所有的文件，因为它可以按原样工作。

把时间浪费在这种意义非常可疑的活动上？我想骗谁呢？编译器？

那些 "有经验 "的同志似乎害怕它的严厉声音，认为它在所有事情上都是正确的。所以他们试图适应，即使这没有意义。

我的标记语言代码中有成千上万的警告，因为我必须在常量前加上（sring）。我可以想象，如果我在每个数字前加一个类型转换，代码会是什么样子。但至少不会有任何警告。
 
Реter Konow:
是的，通过操纵预处理程序，你可以使每个文件单独编译而不出错。

但这正是错误所在。它们是一个整体的一部分，不应该 "描绘 "出独立于其他部分的形象。而事实上，用户可能决定不需要所有的文件，因为它可以按原样工作。

把时间浪费在这种意义非常可疑的活动上？我想骗谁呢？编译器？

那些 "有经验 "的同志似乎害怕它的严厉声音，认为它在任何事情上都是正确的。所以他们试图适应，即使这毫无意义。

我的标记语言代码中有成千上万的警告，因为我必须在常量前加上（sring）。我可以想象，如果我在每个数字前加一个类型转换，代码会是什么样子。但至少不会有任何警告。

有一些同志正在编写一个单独的软件，稍稍改变了元编辑器本身的界面--只为了方便使用！这就是我们的工作。

这个标准就像使用键盘--而不是通过吱吱作响的摩斯密码打出字母。除了在编译时不断地在文件之间翻转，存根不会改变任何东西。但一个存根是2行代码。我们会花多少时间在这个浏览上，只是为了按一个按钮。还有，我们将翻7次，什么会变得更加理性，以便不浪费我们的生命通过吱吱作响的打字机来打字。

注意，我们不是在谈论对象或类，我们只是在谈论节省时间。你的时间... 而且你可以自己想出一个写这些东西的标准。
 
更不用说用俄语编码了，这在英语开发环境中被默认为是歧视性的。也是为了适应，让我的大脑只剩下30%的性能，而我在俄语中可以使用所有的100%？

这么说来，"专业性 "的价格是很高的。
 
Реter Konow:
更不用说用俄语编码了，默认情况下是被英语开发环境所歧视的。我是否也应该适应，给我的大脑留出仅有的30%的性能，而我可以用尽100%的俄语？

这么说来，"专业性 "的价格是很高的。

专业人士在其代码中使用自己的数据类型。一般来说，他们使用什么语言并不重要。

但是，如果一个函数期望以这种顺序得到一个整数。接受（宽度，高度）。

相反，我们不小心把它弄混了，写成了

接受（高度，宽度）--那么copyulator本身就说我们在这里有一个混合。无论它是否对你有用--它也不是关于语言或对象。就是不用自己去寻找这个错误了

 
Alexandr Andreev:

专业人士在其代码中使用自己的数据类型。他们使用什么语言其实并不重要。

但是，如果一个函数期望以这种顺序得到一个整数。接受（宽度，高度）。

相反，我们不小心把它弄混了，写成了

接受（高度，宽度）--那么复制器本身就说我们在这里有一个混杂的问题。无论它是否对你有用--它也不是关于语言或对象。就是不用自己去寻找这个错误。

这是一个测试现成的解决方案并与用户沟通的分支。

我需要有建设性的测试人员，而不是雄心勃勃的 "专业人士 "来寻找可以抱怨的东西。

我不打算讨论抽象的问题。你是否连接了组装好的面板，发现了bug，报告了它们？非常感谢您!耍小聪明，挑剔你不理解的事情--再见。
 
先生们，聪明的人，你们不属于这里。

对于那些没有跑过编辑，没有连接过小组，但却在 "教书 "的人来说，对话是短暂的。

其余的人，欢迎你们!
 
Алексей Барбашин:

彼得，你可以以任何方式对待我，这是你的权利，但要听从一个稍有经验 的同志的建议。

.......

也别忘了在每个文件中添加一个属性。

#property strict

这个属性对代码进行了更严格的检查。

这是为5--那里总是一样的!

虽然总体上我同意：编译时的大量警告并不能增加对代码的信心。

 
Igor Zakharov:

它是为五人制作的--它总是很严格!

虽然我总体上同意：在编译时出现大量的警告并不能增加对代码的信心。

我将删除这些警告。暂时的。
1...414243444546474849505152535455...59
新评论