我的方法。核心是引擎。 - 页 87

新评论
 
Vasiliy Sokolov:
s.w. 具体到在MT对象中存储字符串的问题上，有一个奇怪的故障。如果你开始压缩数据并在对象名称中使用未打印的字符，在某些情况下你将无法访问该对象。这个故障可能仍然存在，因为它非常特殊，没有多少人知道它，但你还是可能偶然发现它。

我明白了，只有通过实践才能明确地弄清问题。

 
Реter Konow:

亲爱的对手们。

以下是脚本代码，其中。

  1. 衡量将一个字符串 传输到一个Char数组 的时间，用于通过资源将字符串传递给另一个程序，以及从Char数组中检索字符串的时间，用于后续的信息分割和检索。
  2. 衡量将字符串写入MT对象描述的时间和从MT对象描述中检索字符串的时间，用于后续信息的分割和检索。

结果。


彼得，你在错误的地方测试了错误的东西。你所测试的东西在字符串逻辑方面应该有差不多的速度。

你完全误解了我的意思。

我的意思是，你应该停止使用字符串来传递double,long,time,int等。而如果你需要传递文本，那么就把文本字符串翻译成ucar数组。而所有不同类型的混合数据通过union数据结构或这些结构的数组，通过union转换为uint数组，应该通过资源传递，在接收方，这些uint数组应该通过union转换回原始结构。相信我，彼得，丁字裤的速度非常慢，你应该尽可能地避免它们。字符串只需要用于文本和打印输出。

而在你的例子中，你把绩效评估的概念完全搞错了。

特别是通过OBJPROP_TEXT属性，你可以传递一个最大尺寸为63字节的字符串。这不算什么。

虽然你的例子完全没有意义，但我把它修改成更正确的东西，纯粹是为了演示，这是我在复制1000个大小为63字节的不同字符串时得到的结果。

脚本代码见附件。它在MT4和MT5上都可以使用

MT4。

2018.12.19 00:50:14.542 TestStringVsCharArray NZDUSD,Weekly: время через свойство объекта:      2309 правильность копирования - true
2018.12.19 00:50:14.542 TestStringVsCharArray NZDUSD,Weekly: время через uchar массив:          1882 правильность копирования - true

MT5。

2018.12.19 00:32:30.857 TestStringVsCharArray (NZDUSD,M1)       время через свойство объекта:      32811 правильность копирования - true
2018.12.19 00:33:00.678 TestStringVsCharArray (NZDUSD,M1)       время через uchar массив:          364   правильность копирования - true

看来MT5是异步的，所以你的方法要慢100倍，根本不适合MT5。你应该越来越多地关注MT5

那它是什么呢？

StringToCharArray(qwerty,Arr,0,WHOLE_ARRAY);

你至少应该阅读帮助

附加的文件：
TestStringVsCharArray.mq4  6 kb
 
Реter Konow:

亲爱的对手们。

以下是脚本代码，其中。

  1. 衡量将一个字符串 传输到一个Char数组 的时间，用于通过资源将字符串传递给另一个程序，以及从Char数组中检索字符串的时间，用于后续的信息分割和检索。
  2. 衡量将字符串写入MT对象描述的时间和从MT对象描述中检索字符串的时间，用于后续信息的分割和检索。

结果。


仔细阅读并得出结论：https://docs.mql4.com/ru/basis/types/stringconst
为了帮助得出结论。
1.为字符串中的每个字符分配2个字节，Unicode编码。没有充分利用绳子的能力。
2.当使用CharArrayToString函数（以及反向）时，要根据ucar数组中的字符编码进行转换，这也会消耗CPU时间。使用ShortArrayToString（反之亦然）。
试试吧，但要注意，在Unicode中字符串必须以0结尾。
 
Aliaksandr Hryshyn:
仔细阅读并得出结论：https://docs.mql4.com/ru/basis/types/stringconst
我来帮你做结论。
1.为字符串中的每个字符分配2个字节，Unicode编码。没有充分利用绳子的能力。
2.当使用CharArrayToString函数（以及反向）时，要根据ucar数组中的字符编码进行转换，这也会消耗CPU时间。使用ShortArrayToString（反之亦然）。
试试吧，但要注意，在Unicode中，字符串必须以null结尾。

不同意。我们需要Uchar数组作为字符串的中介。而且不存在转换，只是复制字节。

 
Nikolai Semko:

我不同意。我们需要一个Uchar数组来作为字符串的中介。而且不存在转换，只是复制字节。

尝试通过西里尔字符。并比较ucar数组和字符串中的字符编码，字符串是作为ushort数组传递的。
 
Aliaksandr Hryshyn:
尽量使用西里尔字母的字符。比较ucar数组和字符串中的字符编码，字符串就像ushort数组。

我知道什么是unicode。但在我们的案例中，我们只需要Uchar数组，通过union得到uint数组，以进一步通过资源传递，当得到回链的字符串恢复。不会有任何损失。而在这种情况下，我们不需要从Uchar数组中提取字符。

编码可以改变，默认为非unicode。

 
Nikolai Semko:

彼得，你在错误的地方测试了错误的东西。你所测试的东西在字符串逻辑方面应该有差不多的速度。

尼古拉，恕我直言，那是白白的空话。我已经测量并附上了一个脚本。"正确的方式，错误的方式......"，"在字符串逻辑方面，应该有大约相同的速度"......只言片语。

尼古拉-森科。

...

你完全误解了我的意思。

我的信息是，你应该停止使用字符串来传递double、long、time、int等。而如果你需要传递文本，那么就把文本字符串转换为Uchar数组。而所有不同类型的混合数据通过union数据结构或这些结构的数组，通过union转换为uint数组，应该通过资源传递，在接收方，这些uint数组应该通过union转换回原始结构。相信我，彼得，丁字裤的速度非常慢，你应该尽可能地避免它们。字符串只需要用于文本和打印输出。

这正是你的信息，我完全理解。而这是错误的。

为什么？- 因为你将不得不使控制参数 的工作系统变得非常复杂。存储、传递和管理参数的架构将变得非常复杂和混乱，这将导致很多问题和整体速度下降。

你不了解内部架构。你不知道程序是如何互动的，根据它们的类型和属性来管理参数值。你的建议会使事情变得更加复杂和混乱。而且这也不能解决沟通问题。它仍将是拐杖式的。

Nikolai Semko:

...

你更可以通过OBJPROP_TEXT属性传递一个最大尺寸为63字节的字符串。这不算什么。

虽然你的例子完全没有意义，但我纯粹是为了演示而把它改得更正确，下面是我复制1000个大小为63字节的不同字符串时得到的结果。

...

你可以通过一个MT-对象的描述传递一个64个字符的字符串。这就够了。我需要 - 20-30行来传输大表的数据。如果没有大型表格，我最多需要2-3行。

我目前对MT4感兴趣。

MT5一直在发展。开发人员只需添加MT-程序的普通内存（这样他们就不必在资源方面大动干戈），这个问题就会被删除。

 

Nikolai Semko:

...

我的意思是，我们应该停止使用字符串来传递double、long、time、int等。

...

你是如何转移double,long,time,int等。???

同样，我们需要将其转换为字符串，然后再转换为char，将其写入资源中。

还是你建议使用lparam,dparam？

也就是说，超载的事件队列...

 
Реter Konow:


遗憾的是。我不谈这个话题了。
幼儿园，第二季度。
你让我感到厌烦，彼得，你的文盲和无知，以及你过度的自我优越感和权利。
 
Nikolai Semko:


另外，在你的测量中，你忘了加上保存和阅读资源的时间......。

因此，即使你写了1000行（这确实最好通过资源），由于保存和从资源中检索的成本，你的速度并没有提高。

1...808182838485868788899091929394...184
新评论