追踪任务（构建一个函数图）。 - 页 5

新评论
 
jartmailru:
静态代码分析...执行是不需要的。

我在考虑另一个选择--解析文本。所以说，解析MQL并创建一个程序结构。
但我甚至不知道该从哪里开始。

 
tara:

为什么不呢，如果你喜欢。

选择错误的执行手段表明不专业。
 
MetaDriver:

这个 问题是无法解决的，这不是很明显吗？这样，我们就可以取消成对的算术（）[] 和运算符{} 括号，用一个单一的开口括号来代替它们。这是不是太弱了？

;)

为什么？

毕竟，也有很多单项操作。


jartmailru:
选择错误的执行手段表明不专业。

你用什么编程有什么区别呢？在任何企业中，重要的是解决方案矩阵。
其他一切都无关紧要。
 
jartmailru:
静态代码分析...执行是不需要的。
代码被分解成功能（块），然后分析谁调用谁。

我心中也有同样的想法。只有对整个程序进行彻底的解析，才能把山和丘陵分开......。

而且似乎主角不需要它，如果我猜得没错的话，他需要打印事实上的电话。比如说，如果通话的条件发生了。

 
sergeev:

我在考虑另一个选择--解析文本。可以说，解析MQL并创建一个程序结构。
但我甚至不知道该从哪里开始实施。

这是最基本的。
什么是函数？
.
[单词空间/它可能不是]单词功能名称括号"（"，那里的东西，括号关闭"）"
卷曲的开瓶器 {
.
一些代码
大括号 {, }
.
卷曲的关闭 }
.
第一部分的工作已经完成。
 
sergeev:

:))

任务（如果你读了第一篇帖子）是在源代码的每个函数中只添加一个服务函数--就在"{"后面。

但以这样的方式获得所有的源代码通道并建立一个调用树。

在这种情况下，源函数的输入参数，以及它们的结果或内部代码都不会有任何改变。



这与纯粹的痕迹无关。这只是关于构建一个函数图。

下面是日志的一个片段。 

01:45:18 CTA0 USDCHF,H1: loaded successfully
01:45:18 CTA0 USDCHF,H1 inputs: BarsBeforeActivate=1; BarsBeforeConfirm=0; TraceIsAllowed=true; IsStaticMode=false; ClearAtFinish=true; ExcludeFirstBar=false; ExcludeLastBar=true; RasingLinesColor=(0,128,128); ReducingLinesColor=(255,0,255); 
01:45:18 CTA0 USDCHF,H1: Init
01:45:18 CTA0 USDCHF,H1: Init=>NewBar(DeadLine)
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>DeleteGroup(Init)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup=>ClearTrend
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup=>ClearTrend=>ClearTrace
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)=>ClearTrend
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)=>ClearTrend=>ClearTrace
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>SaveGroup(Empty)
01:45:18 CTA0 USDCHF,H1: Init=>PaintGroup(ClearScreen)
 
sergeev:

为什么？

毕竟，单数运算的数量并不少。

那么，这个操作显然不是单项的。静态文本分析中的 "嵌套状态 "是单数的。在动态追踪中，它是二进制的。有一个INPUT和一个OUTPUT。

不是有吗？

 
MetaDriver:

我心中也有同样的想法。只有对整个程序进行彻底的解析，才能把山和丘陵分开......。

而在我看来，这并不是起动者所需要的，如果我的直觉正确的话，他需要打印出事实中的电话。你知道，如果呼叫的条件得到满足。

在解析时，实际的调用将被自己检测出来。谁和谁在一起，从哪里来...

所以这是迄今为止唯一完整的解决思路。

 
没有 "彻底 "的解析以及 "山 "和 "疙瘩"...
.
顺便说一下...我再补充一下。
.
- 最初，程序文本由一个 "词典 "进行分析。
词汇器将程序文本打成 "标记"。
在我们的案例中，这些代币是。
.
- 留白 - 空格、制表符、行尾等。-
因为我们不写格式化程序，所以我们只是忽略这些东西
- 小括号 ( / )
- 小括号 [ / ]
- 大括号 { / }
- 操作员 + - / *
- 通配符;。
其余的基本上都是标识符
(数字也会在这一组中--但我们不关心）。
.
在解析 词法时，类型为
struct { typeToken, stringToken }
.
对于解析，我使用了一个类型为
结构 Tocken { typeToken, stringToken, list<Token> list of nested tokens }
但你可以在这里想到一个更简单的方法。
.
然后做我上面提到的分组--微不足道。
.
实际上，词法分析器+解析器的组合是该类型的一个经典。
关于lex/flex/bison/ant-lr不能提供建议（我甚至不知道名字；-D）-。
我写的正是手工制作。
 

好的，谢谢大家的辩论。

123456789
新评论