mql5中的OOP、模板和宏,细微之处和用途 - 页 6 12345678910111213...28 新评论 Alexey Navoykov 2019.01.25 12:06 #51 Alexey Viktorov:在这里,我们走了。 所以你所有的代码都是用拐杖做的?这不是针对个人的。 是的,大约是这样。 因为MQL没有成熟的OOP,再加上有很多bug,我经常报告,但没有成功。 而我不得不用拐杖来保护自己的bug,我还能做什么。 Ilyas 2019.01.25 12:10 #52 我们是这样做的。 如果静态变量是用常数初始化的,这个初始化将在全局初始化步骤中完成,就像以前一样 否则(调用或变量初始化),静态变量将在第一次引用时被初始化(就像在C++中一样),这个引用本身将被包裹在一个带有隐含全局变量/标志 的条件中,例如 为MQL代码。 class CFoo { }; void func(bool f) { if(f) { static CFoo foo; foo.MakeMeHappy(); } } 将生成以下伪代码 CFoo static_func_foo={}; // zeromem only bool static_func_foo_init=false; void func(bool f) { if(f) { if(!static_func_foo_init) { static_func_foo.CFoo(); // constructor call static_func_foo_init=true; } static_func_foo.MakeMeHappy(); } } Ilya Malev 2019.01.25 12:18 #53 Alexey Navoykov:你仍然必须在函数中以某种方式将它们分开。不一定,也不总是。我不会给你举例子,以免乱了阵脚。 Alexey Navoykov 2019.01.25 12:24 #54 Ilyas:下面是我们要做的事情。 好消息!诸神毕竟听到了我们的祈祷)。 Alexey Viktorov 2019.01.25 13:12 #55 Alexey Navoykov: 是的,大约是这样。 因为MQL没有成熟的OOP,再加上有很多bug,我经常报告,但没有成功。 面对这些bug,我不得不用拐杖为自己辩护,我能做什么呢?你把我搞糊涂了。如果在...读你的话 关于交易、自动交易系统和策略测试的论坛 mql5的特殊性,技巧和窍门 Alexey Navoykov, 2019.01.25 11:44 如果参数的类型不同,合理的做法是用相应的类型做几个重载方法,反正你要在函数中共享它们,所以最好把它们分成独立的函数,而不是搞得一团糟,此外还需要一个非个人的类型,即你可以错误地把所有东西都传给它,在库里面得到一个编译错误,那就不好了。 或者甚至可能得不到,那就加倍不好了)。 简而言之,在成熟的OOP中,模板函数是一个拐杖(除了少数例外)。 而且在MQL中也没有成熟的OOP...连拐杖都不见了?我根本就不明白什么。 Ilya Malev 2019.01.25 13:17 #56 MQL与OOP的关系都很好,如果加入多重继承(至少对接口来说,因为它们在目前的形式下是无用的),它将是完美的。 Alexey Navoykov 2019.01.25 13:36 #57 Ilya Malev: MQL在OOP方面是没问题的,如果他们增加多重继承(至少对接口而言,因为它们在目前的形式下是无用的),它将是完美的。所以,接口是正常OOP的基础,而你说在MQL中一切都很好。 Ilya Malev 2019.01.25 13:38 #58 Alexey Navoykov:所以,接口是正常OOP的基础,而你却说MQL中一切正常。正常OOP的基础是多态性,而不是接口。接口是某种类结构 的基础。总的来说,我很想谈论这些话题,但恐怕这个主题不是讨论的地方。 Alexey Navoykov 2019.01.25 14:04 #59 Ilya Malev:正常OOP的基础是多态性,而不是接口。接口是某种类结构 的基础。一般来说,我很乐意讨论这些话题,但恐怕这个分支不适合讨论。我们正在讨论MQL语言的特殊性,没有多重继承是一个相当大的特点)。 好吧,基础当然是多态性,但如果没有独立的接口,在使用上就不方便了。这常常导致传递对象作为模板参数而不是接口。 我在这里 描述了我模拟多个接口的变体。 相应地,一个类可以被声明为 class A : public Interface1<Interface2<Interface3<CBase>>> { ... }; Ilya Malev 2019.01.25 14:16 #60 Alexey Navoykov:我们正在讨论MQL语言的特殊性,没有多重继承是一个相当特殊的问题)。 好吧,基础当然是多态性,但如果没有独立的接口,在使用上就不方便了。这常常导致传递对象作为模板参数而不是接口。 我在这里 描述了我模仿多个接口的变体。 相应地,一个类可以被声明为这样。 在我看来,这并不全是坏事。在C#中,没有那么多基本的主接口,以至于它们的方法不能被简化为一个基本的超类,然后被继承。 P.S. 要想通过<<<<>>>> 这样的结构来实现一些多重的东西,是有点麻烦的。最好是通过运算符来做函数,例如,a==b调用a.compareto( b ),a[compareer]==b调用compareer.compare(a,b)等等。 12345678910111213...28 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
在这里,我们走了。
我们是这样做的。
如果静态变量是用常数初始化的,这个初始化将在全局初始化步骤中完成,就像以前一样
否则(调用或变量初始化),静态变量将在第一次引用时被初始化(就像在C++中一样),这个引用本身将被包裹在一个带有隐含全局变量/标志 的条件中,例如
为MQL代码。
将生成以下伪代码
你仍然必须在函数中以某种方式将它们分开。
不一定,也不总是。我不会给你举例子,以免乱了阵脚。
下面是我们要做的事情。
是的,大约是这样。 因为MQL没有成熟的OOP,再加上有很多bug,我经常报告,但没有成功。 面对这些bug,我不得不用拐杖为自己辩护,我能做什么呢?
你把我搞糊涂了。如果在...读你的话
关于交易、自动交易系统和策略测试的论坛
mql5的特殊性,技巧和窍门
Alexey Navoykov, 2019.01.25 11:44
如果参数的类型不同,合理的做法是用相应的类型做几个重载方法,反正你要在函数中共享它们,所以最好把它们分成独立的函数,而不是搞得一团糟,此外还需要一个非个人的类型,即你可以错误地把所有东西都传给它,在库里面得到一个编译错误,那就不好了。 或者甚至可能得不到,那就加倍不好了)。
简而言之,在成熟的OOP中,模板函数是一个拐杖(除了少数例外)。
MQL在OOP方面是没问题的,如果他们增加多重继承(至少对接口而言,因为它们在目前的形式下是无用的),它将是完美的。
所以,接口是正常OOP的基础,而你说在MQL中一切都很好。
所以,接口是正常OOP的基础,而你却说MQL中一切正常。
正常OOP的基础是多态性,而不是接口。接口是某种类结构 的基础。总的来说,我很想谈论这些话题,但恐怕这个主题不是讨论的地方。
正常OOP的基础是多态性,而不是接口。接口是某种类结构 的基础。一般来说,我很乐意讨论这些话题,但恐怕这个分支不适合讨论。
我们正在讨论MQL语言的特殊性,没有多重继承是一个相当大的特点)。
好吧,基础当然是多态性,但如果没有独立的接口,在使用上就不方便了。这常常导致传递对象作为模板参数而不是接口。
我在这里 描述了我模拟多个接口的变体。 相应地,一个类可以被声明为
我们正在讨论MQL语言的特殊性,没有多重继承是一个相当特殊的问题)。
好吧,基础当然是多态性,但如果没有独立的接口,在使用上就不方便了。这常常导致传递对象作为模板参数而不是接口。
我在这里 描述了我模仿多个接口的变体。 相应地,一个类可以被声明为这样。
在我看来,这并不全是坏事。在C#中,没有那么多基本的主接口,以至于它们的方法不能被简化为一个基本的超类,然后被继承。
P.S. 要想通过<<<<>>>> 这样的结构来实现一些多重的东西,是有点麻烦的。最好是通过运算符来做函数,例如,a==b调用a.compareto( b ),a[compareer]==b调用compareer.compare(a,b)等等。