错误、漏洞、问题 - 页 1337

[Artyom Trishkin]

Vladimir Pastushak:

开发商并非毫无幽默感。

在我看来，这听起来像是下载，以及 "下载 "那种向右或向左摆动的树。

如果 "摇摆"，你也可以把它比作一棵树："右/左"--你也很幽默（把 "右/左 "混为一谈）。

[Vladimir Pastushak]

Artyom Trishkin:
如果 "摇摆"，你可以把它比作一棵树："右/左"--你也很幽默（融合 "右/左"）。

在船上的 "摇摆",

而 （右/左融合） 的事情 不是我的错，是火狐的错。

[Andrey Dik]

如果你在ME中编译文件，躺在Projects文件夹中，编译后的文件会在相应的文件夹Experts, Indicators, Scripts中创建。但如果我用一个单独的编译器进行编译，这种情况就不会发生--编译后的文件会在有源代码的文件夹中创建。它应该是这样的，还是应该使用适当的键？

[unreal]

在BR-8.15和BR-10.15字符上出现故障，其他BR时期则正常。

建立1150真正的开放win7 x64最大

拖车中的视频文件.mp4。

+关于M1期（例如）

如果你按下 "随着新刻度的到来，自动滚动图表到最后 "的按钮--图表被转移到开头

然后，如果你按下 "END "键，图表就会移动到终点一秒钟，然后再一次--转移到起点。

[Ilyas]

Alexey Navoykov:

我以前没怎么注意，但现在，在处理大的类对象数组时，我注意到内存消耗太大。 我通过sizeof()检查，一个绝对空的类需要16字节。 考虑到这里的类是被管理的，我们为每个指针再加8字节。 总共是24字节。 这相当有点多。

我翻阅了文档，看到了我在那里发现的东西。

问题是为什么简单的类（不参与继承的类）需要虚拟函数 表，因为在编译阶段就知道这些类的一切。

事实证明，其中的方法是以与虚拟方法相同的方式调用的，也就是说，有额外的通过表的访问重定向。 那么，被称赞的编译器优化在哪里呢？ 我们怎么能说在这之后与C++的性能有任何比较？

突出显示的假设是不正确的，只有虚拟方法是通过表调用的，我的声明不仅对MQL编译器是正确的。
此外，MQL，一些虚拟调用是作为正常的函数调用执行的，而不是通过表。
正如Renat所写的，MQL中的类确实总是有一个虚拟表，它需要8个字节+8个字节的元信息。

[[删除]]

Vladimir Pastushak:

开发商并非毫无幽默感。

在我看来，这听起来像是下载，以及 "下载 "那种向右或向左摆动的树。

谢谢你，改成了 "下载"。

[Alexey Navoykov]

Ilyas:
突出显示的假设是不正确的，只有虚拟方法是通过表调用的，我的声明不仅对MQL编译器是正确的。
另外，MQL，一些虚拟调用是作为正常的函数调用，而不是通过表。
正如Renat所写的，MQL中的类确实总是有一个虚拟表，需要8个字节+8个字节的元信息。

总之，你能不能澄清一下，为什么一个简单的类，不继承任何人，因此不参与虚拟化，需要一个表？ Renat提到了虚拟析构器，但在这种情况下，我们没有什么要虚拟化的。只有一个析构器，所以它也可以被内联，不是吗？ 这样就只剩下8字节的元数据了。

[Ilyas]

Alexey Navoykov:
谢谢你的回答，但你能不能解释一下，为什么一个简单的类，没有继承自任何人，因此不参与虚拟化，需要一个表？ Renat提到了虚拟析构器，但在这种情况下，没有什么需要虚拟化。只有一个析构器，所以它也可以被内联，不是吗，从而只留下8字节的元数据。

如果一个类没有被继承，它的析构器会作为一个普通的非虚拟函数被调用，如果它符合内联标准，则被内联。

运行时系统（MQL程序环境）的建立是假设一个类至少占据16个字节。

[Andrey Dik]

如果你在ME中编译文件，躺在Projects文件夹中，编译后的文件会在相应的文件夹Experts, Indicators, Scripts中创建。但如果我用一个单独的编译器进行编译，这种情况就不会发生--编译后的文件会在有源代码的文件夹中创建。它应该是这样的，还是应该使用适当的键？

[Vladimir Pastushak]

建854 VIN 10 64 X

当用可视化的方式测试EA 时，当试图关闭除当前工作窗口外的任何其他先前打开的窗口时，测试被打断......

通过鼠标中键和上下文菜单关闭 ...