我的方法。核心是引擎。 - 页 84 1...777879808182838485868788899091...184 新评论 Nikolai Semko 2018.12.17 21:37 #831 Maxim Kuznetsov:是的，在MQL中解析文本是非常有趣的 :-)嗯，它不是为文本解析而设计的。我的意思是，你可以，但这是一个无赖......。 数组和订单--这就是MQL的意义所在这就是我所说的...:) Реter Konow 2018.12.17 21:39 #832 Nikolai Semko:多才多艺往往是迟钝的代名词，对字符串更是如此。 让我给你举一个例子。我曾经用WebRequest解析了一个从加密交易所收到的字符串。而我使用Sergeev的JSON库 对其进行解析，他是从 "高速C++库 "移植过来的。而且我注意到，速度非常不理想。在那里，一切都通过 "通用 "字符串完成。我了解到速度低的原因是字符串，想避免使用字符串函数，于是写了一个直接从ucar数组中解析的函数。结果让我相当惊讶。我的解析速度是....(鼓声）800倍的速度。如果通过JSON解析整个字符串需要0.3秒，那么我的函数在不到半毫秒的时间内就解析完毕。下面 是我通过Uchar数组进行解析的例子。你的建议的要点如下。 我们取一个字符串（640个字符），把它送到StringToChar()函数。我们得到数组并将其存储在资源中。使用ResourceReadImage()获取第二面的资源内容到第二个数组。将第二个数组发送到CharArrayToString()，得到最终的字符串。接下来，用分隔符分割字符串，并将参数值写到内核中。我原本想用MT对象来传输字符串。 我们取一个字符串（640个字符），并将其分成若干部分，每部分64个字符。我们在通信对象上做一个循环，并在它们的描述中写入字符串的部分。在第二方面，在通信对象上做一个循环，得到字符串的一部分，每一部分被分隔符分割，提取参数编号和值。我们把参数值写入内核。第二种变体最初对我来说似乎更快。 当你像我一样有这么多任务时，在选择解决方案时，你必须依靠自己的直觉。你不会有足够的生命来彻底检查所有的东西。在选择正确的方向时，你要么需要一个团队，要么需要一种伟大的直觉。当然，你还必须牺牲专业精神，忍受知识上的差距。否则，你将只能做涂鸦（尽管是专业的），永远无法完成一个大型项目。这就是现实。 Nikolai Semko 2018.12.17 21:43 #833 Реter Konow:你的建议的要点如下。 我们取一个字符串（640个字符），把它送到StringToChar()。我们得到一个数组并将其存储在一个资源中。使用ResourceReadImage()获取第二面的资源内容到第二个数组。将第二个数组发送到CharArrayToString()，得到最终的字符串。接下来，用分离器分割字符串，并将参数值写入内核。 完全不是这样的。 我现在很忙--没有时间解释。 如果你把我的代码 详细地拆开，不留下任何空白点，你会为自己带来很多发现。 只是如果没有调试器，就更难搞清楚了。我不知道你是否开始使用它，或者你仍然不使用这个重要的工具。 Реter Konow 2018.12.17 21:54 #834 Nikolai Semko:... 如果你详细检查我的代码，不要留下空白点，你会有很多新发现。 只有在不使用调试器的情况下，才会更难理解。我不知道你是否开始使用它，或者你仍然不使用这个重要的工具。我明天会仔细看一下你的代码。(不要忘记时区)。 也许确实如此，我将发现一些新的东西。)) Алексей Тарабанов 2018.12.17 22:11 #835 任何结构都是一个字符串。结构数组是一个带有格式描述的字符串数组。类--结构和方法，类的实现--实现的阵列（原谅我的法语）。 你不需要在最后一刻才转换什么。到处都只涉及字符串。简单地说，它们被规范化了：有些需要2个，或4个字节，有些需要1个，所以你必须对齐。 我第一次使用这种方法是在1993年左右，Clarion DBMS。它的工作非常迅速。 Maxim Kuznetsov 2018.12.17 22:24 #836 Алексей Тарабанов:任何结构都是一个字符串。结构数组是一个带有格式描述的字符串数组。类--结构和方法，类的实现--实现的阵列（原谅我的法语）。 你不需要在最后一刻才转换什么。到处都只涉及字符串。简单地说，它们被规范化了：有些需要2个，或4个字节，有些需要1个，所以你必须对齐。 我第一次使用这种方法是在1993年左右，Clarion DBMS。这一切都非常迅速地发挥作用。大约在相同的时间，相同的:-)一所学校......顺便说一下，DBMS并不坏，在很多方面都领先于它的时代。 PS/有时会有一种被热捧的痒痒，在 "一切是字符串/文本 "的概念层面上的后发制人。其速度确实达到了python的水平。 Nikolai Semko 2018.12.17 23:50 #837 Реter Konow:我明天会仔细看一下你的代码。(不要忘记时区)。 也许我真的会发现新的东西。))也许这将是有用的 在双例上使用资源变量的指标的例子，在改变TF时不重新初始化其值。这是对终端的全局变量 的一种更方便的替代。以同样的方式，不同的数据结构和这些结构的数组可以作为全局结构使用。 附加的文件： Variable.mqh 7 kb TestResVar.mq5 3 kb Алексей Тарабанов 2018.12.18 00:04 #838 Nikolai Semko:它仍然可能派上用场。) Vasiliy Sokolov 2018.12.18 08:44 #839 Реter Konow: 为了有趣起见，我将尝试用联合的变体。并用CharArrayToString和StringToCharArray。虽然我的直觉告诉我，它几乎不会比通过描述МТ对象的通信快。但我可能是错的。让我们来看看...彼得，你从一开始就做了一张外卡，现在你又在争论你的外卡内的信息传递性能问题。你明白了吧：字符串只是一个方便的***，仅此而已。任何数据实际上都只是内存中的一个字节集合。所以建议你直接处理字节，但你一如既往地固执己见，不明白同一个字符串就是同一个字节数组。因此，在将字符串转换为Uchar数组时，你不会有任何损失。 但在解析字符串时，你的性能就真的变慢了。这就是为什么你所有的直觉就是不见了。 Реter Konow 2018.12.18 09:16 #840 Vasiliy Sokolov:1.彼得，你最初做了一个游戏，现在你在争论你游戏中的信息传递性能。 2.你明白：字符串只是一个方便的***，仅此而已。任何数据实际上都只是内存中的一个字节集合。所以，他们建议你直接用字节工作，但你却一如既往地固执己见，不明白同一个字符串就是同一个字节数组。因此，在字符串到Uchar数组的转换中，你不会有任何损失。 但当你解析字符串时，你的性能真的会变慢。 3.因此，你所有的直觉都只是一种错过。 1."野性"--在这种情况下，是你的理解，而不是我做了什么。花了75页，你才明白它是怎么回事，发动机是怎么回事。理解：缺陷和错误并不代表一个实体的特征。 本质的任何形式都不能说明本质本身的特征。就像你的衣服并不决定你是什么样的人。只有错误的思维才会以特定的方式判断整体。 2.对我来说，这很清楚，因为它是。我今天将检查使用StringToChar函数是否会有真正的速度提升。 3.每天我都检查我的直觉。我每天都在怀疑。这也是正确的。如果它失败了，你应该以理性为指导。但 "理性 "太过有限、傲慢和愚蠢，不能总是依赖它。因此，直觉是唯一的选择。如果你知道我的意思... 1...777879808182838485868788899091...184 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
是的，在MQL中解析文本是非常有趣的 :-)嗯，它不是为文本解析而设计的。我的意思是，你可以，但这是一个无赖......。
数组和订单--这就是MQL的意义所在
这就是我所说的...:)
多才多艺往往是迟钝的代名词，对字符串更是如此。
让我给你举一个例子。
我曾经用WebRequest解析了一个从加密交易所收到的字符串。而我使用Sergeev的JSON库 对其进行解析，他是从 "高速C++库 "移植过来的。而且我注意到，速度非常不理想。在那里，一切都通过 "通用 "字符串完成。
我了解到速度低的原因是字符串，想避免使用字符串函数，于是写了一个直接从ucar数组中解析的函数。结果让我相当惊讶。我的解析速度是....(鼓声）800倍的速度。如果通过JSON解析整个字符串需要0.3秒，那么我的函数在不到半毫秒的时间内就解析完毕。
下面 是我通过Uchar数组进行解析的例子。
你的建议的要点如下。
我原本想用MT对象来传输字符串。
第二种变体最初对我来说似乎更快。
当你像我一样有这么多任务时，在选择解决方案时，你必须依靠自己的直觉。你不会有足够的生命来彻底检查所有的东西。在选择正确的方向时，你要么需要一个团队，要么需要一种伟大的直觉。当然，你还必须牺牲专业精神，忍受知识上的差距。否则，你将只能做涂鸦（尽管是专业的），永远无法完成一个大型项目。这就是现实。
你的建议的要点如下。
完全不是这样的。
我现在很忙--没有时间解释。
如果你把我的代码 详细地拆开，不留下任何空白点，你会为自己带来很多发现。
只是如果没有调试器，就更难搞清楚了。我不知道你是否开始使用它，或者你仍然不使用这个重要的工具。
...
如果你详细检查我的代码，不要留下空白点，你会有很多新发现。
只有在不使用调试器的情况下，才会更难理解。我不知道你是否开始使用它，或者你仍然不使用这个重要的工具。
我明天会仔细看一下你的代码。(不要忘记时区)。
也许确实如此，我将发现一些新的东西。))
任何结构都是一个字符串。结构数组是一个带有格式描述的字符串数组。类--结构和方法，类的实现--实现的阵列（原谅我的法语）。
你不需要在最后一刻才转换什么。到处都只涉及字符串。简单地说，它们被规范化了：有些需要2个，或4个字节，有些需要1个，所以你必须对齐。
我第一次使用这种方法是在1993年左右，Clarion DBMS。它的工作非常迅速。
任何结构都是一个字符串。结构数组是一个带有格式描述的字符串数组。类--结构和方法，类的实现--实现的阵列（原谅我的法语）。
你不需要在最后一刻才转换什么。到处都只涉及字符串。简单地说，它们被规范化了：有些需要2个，或4个字节，有些需要1个，所以你必须对齐。
我第一次使用这种方法是在1993年左右，Clarion DBMS。这一切都非常迅速地发挥作用。
大约在相同的时间，相同的:-)一所学校......顺便说一下，DBMS并不坏，在很多方面都领先于它的时代。
PS/有时会有一种被热捧的痒痒，在 "一切是字符串/文本 "的概念层面上的后发制人。其速度确实达到了python的水平。
我明天会仔细看一下你的代码。(不要忘记时区)。
也许我真的会发现新的东西。))
也许这将是有用的
在双例上使用资源变量的指标的例子，在改变TF时不重新初始化其值。这是对终端的全局变量 的一种更方便的替代。以同样的方式，不同的数据结构和这些结构的数组可以作为全局结构使用。
它仍然可能派上用场。
)
为了有趣起见，我将尝试用联合的变体。并用CharArrayToString和StringToCharArray。虽然我的直觉告诉我，它几乎不会比通过描述МТ对象的通信快。但我可能是错的。让我们来看看...
彼得，你从一开始就做了一张外卡，现在你又在争论你的外卡内的信息传递性能问题。你明白了吧：字符串只是一个方便的***，仅此而已。任何数据实际上都只是内存中的一个字节集合。所以建议你直接处理字节，但你一如既往地固执己见，不明白同一个字符串就是同一个字节数组。因此，在将字符串转换为Uchar数组时，你不会有任何损失。 但在解析字符串时，你的性能就真的变慢了。这就是为什么你所有的直觉就是不见了。
1.彼得，你最初做了一个游戏，现在你在争论你游戏中的信息传递性能。
2.你明白：字符串只是一个方便的***，仅此而已。任何数据实际上都只是内存中的一个字节集合。所以，他们建议你直接用字节工作，但你却一如既往地固执己见，不明白同一个字符串就是同一个字节数组。因此，在字符串到Uchar数组的转换中，你不会有任何损失。 但当你解析字符串时，你的性能真的会变慢。
3.因此，你所有的直觉都只是一种错过。
1."野性"--在这种情况下，是你的理解，而不是我做了什么。花了75页，你才明白它是怎么回事，发动机是怎么回事。理解：缺陷和错误并不代表一个实体的特征。 本质的任何形式都不能说明本质本身的特征。就像你的衣服并不决定你是什么样的人。只有错误的思维才会以特定的方式判断整体。
2.对我来说，这很清楚，因为它是。我今天将检查使用StringToChar函数是否会有真正的速度提升。
3.每天我都检查我的直觉。我每天都在怀疑。这也是正确的。如果它失败了，你应该以理性为指导。但 "理性 "太过有限、傲慢和愚蠢，不能总是依赖它。因此，直觉是唯一的选择。如果你知道我的意思...