mql5中的OOP、模板和宏，细微之处和用途 - 页 9 12345678910111213141516...28 新评论 Alexey Navoykov 2019.01.25 16:08 #81 Ilya Malev:我得到了 "堆栈溢出" ) 我想它毕竟是一只蟑螂......嗯，这不是编译器的问题，而是在运行时。 编译器应该做出反应。 以下是我在VS 2010中的尝试。 class A { public: virtual int f2() = 0; }; class B : public A { public: virtual int f2() { return A::f2(); } }; B b; 我得到一个编译错误。 错误1 错误LNK2001：未解决的外部符号 "public: virtual __thiscall A::f2(void)"。 但Metaeditor什么都不说。不太好。 Ilya Malev 2019.01.25 16:29 #82 事实证明，用=0调用 一个祖先函数 会变成调用自己。如果你自己抓住这个错误，你可能会从中受益... Alexey Viktorov 2019.01.25 16:32 #83 Alexey Navoykov:这就是编译器应该有的反应。我在VS 2010中尝试了这个方法。我得到一个编译错误。 错误1 错误LNK2001：未解决的外部符号 "public: virtual __thiscall A::f2(void)"。Metaeditor不会说一个字。不太好。阿列克谢，请向我解释，为什么如果mql是C的副本，它必须是绝对相同的，并且向左走一步，向右走一步--行刑队？ 就因为开发商不小心？但任何语言都是建立在循环和条件之上的。其他东西都在预告片中。为什么没有人要求任何其他语言在OOP部分或其他方面与C类似？ Alexey Navoykov 2019.01.25 16:55 #84 Alexey Viktorov:阿列克谢，请你用手指给我解释一下，为什么如果mql像C一样，那么它一定是绝对相同的，向左走一步，向右走一步--行刑队？ 就因为开发商不小心？但任何语言都是建立在循环和条件之上的。其他东西都在预告片中。为什么没有人要求任何其他语言在OOP部分或其他方面与C类似？ 这并不是说要完全相同。这是关于功能，它的实现必须正确和一致地工作。 但首先 你喊：给我看看另一种工作方式不同的语言。然后当工作方式不同（正确）的C++被作为一个例子时，你又开始老调重弹，说MQL不是C++，不应该相同。 你应该下定决心 Dmitry Fedoseev 2019.01.25 17:10 #85 Alexey Viktorov:你能给我们举个例子吗，这一切能让写代码变得更容易，缩短代码，或者至少能保护它不出错？而且，请不要使用抽象的函数，而是使用最接近真实交易条件的EA或指标。不可能。这些人只是想把他们的幻想变成现实。 Nikolai Semko 2019.01.25 17:27 #86 Dmitry Fedoseev:不可能。这些人只是想把他们的幻想延伸到现实中。 在我看来，这是一个非常有用的练习--将幻想延伸到现实。这就是发展的意义所在!非常有启发性的讨论。(笑）：谢谢。 Ilya Malev 2019.01.25 17:32 #87 Alexey Navoykov:是的，但我长期以来一直在使用一种替代方案：所有的接口最初都被设计成一个中间的模板类。 通过这种方式，你可以创建一个由任何数量的此类接口组成的继承链。是的，当然你不能用它们来做dynamic_cast，但这并不是经常需要的。 主要的任务是把它们传递到函数中。我仔细读过了，顺便说一下，这是一个有趣的举动。我之前没有想到 =)我也要做实验，在我的闲暇时间...... Alexey Navoykov 2019.01.25 17:34 #88 Nikolai Semko: 对我来说，这样的练习非常有用--在现实中伸展幻想。这就是发展的意义!一个非常有启发性的讨论。谢谢你。最重要的是--富有成效！开发人员确实听到了我们的意见，并决定修复这个大家多年来一直纠结的错误。 但一些论坛用户的破坏性态度无疑是令人惊讶的--他们不发展自己，却试图以非凡的毅力阻碍他人。 Ilya Malev 2019.01.25 17:49 #89 >> 是的，当然你不能用它们做dynamic_cast，但这并不是一个频繁的需求。 你为什么不这样做，没问题 )但是，你的主要噩梦出现了--在编译阶段没有检测到铸造错误 :) Alexey Navoykov 2019.01.25 18:29 #90 Ilya Malev:>> 是的，当然你不能用它们做dynamic_cast，但这并不是一个频繁的需求。 你为什么不这样做，没问题 )但是，你的主要噩梦出现了--在编译阶段没有检测到铸造错误 :)毕竟，继承链可以是任何你想要的方式：Interface<CBase>或Interface<C<B<A<CBase>>>>，有无数的变体。我们将不得不把CBase一致地投向所有可能的变体，这是不现实的。 我记得我打算在类对象 本身中实现对接口信息的存储，除了现有的接口垫之外，还可以制作独立的接口类，作为我们的垫子的包装。但后来我得出结论，所有这些都是不必要的，没有必要。在实践中，我从未见过需要将基类投给任何接口的情况，这没有任何意义。 唯一的选择是找出该类是否支持这个接口，以达到调试的目的，但我们不需要为此而投。 12345678910111213141516...28 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我得到了 "堆栈溢出" )
我想它毕竟是一只蟑螂......嗯，这不是编译器的问题，而是在运行时。 编译器应该做出反应。
以下是我在VS 2010中的尝试。
我得到一个编译错误。 错误1 错误LNK2001：未解决的外部符号 "public: virtual __thiscall A::f2(void)"。
但Metaeditor什么都不说。不太好。
这就是编译器应该有的反应。
我在VS 2010中尝试了这个方法。
我得到一个编译错误。 错误1 错误LNK2001：未解决的外部符号 "public: virtual __thiscall A::f2(void)"。
Metaeditor不会说一个字。不太好。
阿列克谢，请向我解释，为什么如果mql是C的副本，它必须是绝对相同的，并且向左走一步，向右走一步--行刑队？
就因为开发商不小心？但任何语言都是建立在循环和条件之上的。其他东西都在预告片中。为什么没有人要求任何其他语言在OOP部分或其他方面与C类似？
阿列克谢，请你用手指给我解释一下，为什么如果mql像C一样，那么它一定是绝对相同的，向左走一步，向右走一步--行刑队？
就因为开发商不小心？但任何语言都是建立在循环和条件之上的。其他东西都在预告片中。为什么没有人要求任何其他语言在OOP部分或其他方面与C类似？
你能给我们举个例子吗，这一切能让写代码变得更容易，缩短代码，或者至少能保护它不出错？而且，请不要使用抽象的函数，而是使用最接近真实交易条件的EA或指标。
不可能。这些人只是想把他们的幻想变成现实。
不可能。这些人只是想把他们的幻想延伸到现实中。
是的，但我长期以来一直在使用一种替代方案：所有的接口最初都被设计成一个中间的模板类。
通过这种方式，你可以创建一个由任何数量的此类接口组成的继承链。是的，当然你不能用它们来做dynamic_cast，但这并不是经常需要的。 主要的任务是把它们传递到函数中。我仔细读过了，顺便说一下，这是一个有趣的举动。我之前没有想到 =)我也要做实验，在我的闲暇时间......
对我来说，这样的练习非常有用--在现实中伸展幻想。这就是发展的意义!
最重要的是--富有成效！开发人员确实听到了我们的意见，并决定修复这个大家多年来一直纠结的错误。
但一些论坛用户的破坏性态度无疑是令人惊讶的--他们不发展自己，却试图以非凡的毅力阻碍他人。
>> 是的，当然你不能用它们做dynamic_cast，但这并不是一个频繁的需求。
你为什么不这样做，没问题 )但是，你的主要噩梦出现了--在编译阶段没有检测到铸造错误 :)
>> 是的，当然你不能用它们做dynamic_cast，但这并不是一个频繁的需求。
你为什么不这样做，没问题 )但是，你的主要噩梦出现了--在编译阶段没有检测到铸造错误 :)
毕竟，继承链可以是任何你想要的方式：Interface<CBase>或Interface<C<B<A<CBase>>>>，有无数的变体。我们将不得不把CBase一致地投向所有可能的变体，这是不现实的。
我记得我打算在类对象 本身中实现对接口信息的存储，除了现有的接口垫之外，还可以制作独立的接口类，作为我们的垫子的包装。但后来我得出结论，所有这些都是不必要的，没有必要。在实践中，我从未见过需要将基类投给任何接口的情况，这没有任何意义。 唯一的选择是找出该类是否支持这个接口，以达到调试的目的，但我们不需要为此而投。