给OOP专家的一个问题。 - 页 17 1...101112131415161718192021222324...55 新评论 Реter Konow 2019.08.30 19:19 #161 Vladimir Simakov: 我是指班级的数量。每一个都是200行。 它的访问难度会有多大？我有一个全球性的内核，可以从任何地方看到。在OOP中，我将不得不放弃它。那么我如何在窗口中使用元素呢？当我试图想象它时，我就会昏迷。） Artyom Trishkin 2019.08.30 19:21 #162 Реter Konow: 访问会有多大的难度？我有一个全局内核，从任何地方都可以看到。在OOP中，我将不得不放弃它。那么我如何在窗口中使用元素呢？当我试图想象它时，我就会昏迷。） 静态类。 TheXpert 2019.08.30 19:23 #163 Vladimir Simakov: А теперь к эффективности. Switch - это что в конечном итоге? Это последовательное сравнение параметра с константами. Внимание Петр, последовательное. 完全没有必要。 这并不意味着彼得是正确的，也不意味着应该把开关放在任何地方，但尽管如此。 Vladimir Simakov 2019.08.30 20:40 #164 Alexey Navoykov: 是的，这是正确的，所以就速度而言，它显然是MQL中最快的选项。但在管理环境中对类对象 的访问是间接的。 谢谢你的这一简要概述。我收回我对开关的说法。 [删除] 2019.08.31 08:34 #165 Georgiy Merts: 这是正确的，更多关于这个功能。你有一个巨大的开关，可以选择十几种所需功能中的一种。在这样的切换中，很容易犯错，不小心把与其中一个分支有关的代码写在了错误的地方。 有了过载，事情就简单多了。我们有十个不同的后裔，在任何时候我们都只使用一个类，而且它有一个可重载的函数。我们不能意外地把它写在另一个类中，因为我们必须为它打开一个完全不同的文件。 另外--在我看来，在这个非常巨大的开关中，解析本身比打开我们需要的一个类，然后只解析一个函数要紧张得多。 事实上，在汇编代码中，所有这个开关的处理都归结为同一个开关，取决于这个指针。但在OOP的情况下，所有这些都被隐藏起来，不会干扰到程序员的工作。没有OOP--你就必须处理它。 粗略地说，当你走路时--你最终以一定的顺序向你的肌肉发送信号，使其运动。然而，在意识的层面上--你只是记得要做哪个动作。在这里，OOP正是那种 "记忆要做什么动作"。 你 "不明白为什么我们需要记住动作，因为我们有一堆肌肉，以及与之相连的神经"。 嗯......我以前说过很多次，对于记忆力强的巨人来说，记住哪些肌肉需要按什么顺序绷紧就真的很够了。记住整个运动是没有意义的。对于其他不能记住这么多的人来说，记住整个动作，以及肌肉有什么，以什么顺序绷紧，绷到什么程度--把它藏在心里更合理。 对于编译器来说，重载函数只是不同的函数，而没有开关。 Georgiy Merts 2019.08.31 11:28 #166 Реter Konow: 访问会有多大的难度？我有一个全局内核，从任何地方都可以看到。在OOP中，我将不得不放弃它。那么我如何在窗口中使用元素呢？当我试图想象它时，我就会昏迷。） 为什么会这样呢？ 全局内核和OOP并不相互排斥。 只是窗口中的元素应该被封装在窗口类中，而不是 "躺在明处"。只是为了不让人意外地 "走错地方"。改变一个变量并对其在一个巨大的全局数组中的位置犯错是非常容易的，而查询正确的接口，然后在正确的对象中改变同样的变量并犯错就难多了。 Georgiy Merts 2019.08.31 11:30 #167 Koldun Zloy: 对于编译器来说，重载函数只是不同的函数，而没有开关。 那么如何选择需要的人呢？我们正在谈论虚拟函数 和晚期绑定。哪个重载函数将被调用？这是由this指针决定的，当你调用它时，this指针是隐式传递的。而你认为这种选择是如何作出的？ [删除] 2019.08.31 12:50 #168 Georgiy Merts: 而我们想要的那个人是如何被选中的呢？我们正在谈论虚拟函数 和晚期绑定。哪个重载函数将被调用？这是由this指针决定的，该指针在调用中隐含地传递。而你认为这种选择是如何做出的？ 实际上，彼得并不是在谈论虚拟函数。 但他们也没有任何开关。 一个有虚拟函数的类有一个虚拟函数表。 而这个类的每个对象都包含一个隐性变量--指向虚拟函数表的指针。 如果一个或所有的虚拟函数在子代中被覆盖，就会创建一个新的表，子代实例包含一个指向它的指针。 Georgiy Merts 2019.08.31 13:11 #169 Koldun Zloy: 实际上，彼得并不是在谈论虚拟函数。 但他们也没有任何开关。 一个有虚拟函数的类有一个虚拟函数表。 而这个类的每个对象都包含一个隐性变量--指向虚拟函数表的指针。 如果一个或所有的虚拟函数在子代中被重写，就会创建一个新的表，子代的实例包含一个指向它的指针。 正是如此。我想问的是，这个相同的表格是如何工作的？ 在汇编代码中，它是相同的开关。 而关于 "不谈虚拟函数"--这有点像 "为什么是OOP"...也就是说，它是关于虚拟函数的，而不是关于不同参数的函数的简单相同的名称。 [删除] 2019.08.31 13:15 #170 Georgiy Merts: 正是如此。所以我的问题是：这个非常表是如何工作的？ 在汇编代码中，它是同样的开关。 不，它只是一个指向函数的指针数组。 汇编代码从对象中获取一个表地址。 它在某一位置获取函数的地址。 并对该地址进行了跳转。 那 "我不是在谈论虚拟函数"呢--这就是我说的 "为什么是OOP"...也就是说，它是关于虚拟函数的，而不仅仅是参数不同的函数的相同名称。 从他的问题来看，他说的是具有相同名称的函数。 他很可能甚至没有意识到虚拟功能。 1...101112131415161718192021222324...55 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我是指班级的数量。每一个都是200行。
访问会有多大的难度？我有一个全局内核，从任何地方都可以看到。在OOP中，我将不得不放弃它。那么我如何在窗口中使用元素呢？当我试图想象它时，我就会昏迷。）
静态类。
Vladimir Simakov:
А теперь к эффективности. Switch - это что в конечном итоге? Это последовательное сравнение параметра с константами. Внимание Петр, последовательное.
完全没有必要。
这并不意味着彼得是正确的，也不意味着应该把开关放在任何地方，但尽管如此。
是的，这是正确的，所以就速度而言，它显然是MQL中最快的选项。但在管理环境中对类对象 的访问是间接的。
这是正确的，更多关于这个功能。你有一个巨大的开关，可以选择十几种所需功能中的一种。在这样的切换中，很容易犯错，不小心把与其中一个分支有关的代码写在了错误的地方。
有了过载，事情就简单多了。我们有十个不同的后裔，在任何时候我们都只使用一个类，而且它有一个可重载的函数。我们不能意外地把它写在另一个类中，因为我们必须为它打开一个完全不同的文件。
另外--在我看来，在这个非常巨大的开关中，解析本身比打开我们需要的一个类，然后只解析一个函数要紧张得多。
事实上，在汇编代码中，所有这个开关的处理都归结为同一个开关，取决于这个指针。但在OOP的情况下，所有这些都被隐藏起来，不会干扰到程序员的工作。没有OOP--你就必须处理它。
粗略地说，当你走路时--你最终以一定的顺序向你的肌肉发送信号，使其运动。然而，在意识的层面上--你只是记得要做哪个动作。在这里，OOP正是那种 "记忆要做什么动作"。 你 "不明白为什么我们需要记住动作，因为我们有一堆肌肉，以及与之相连的神经"。 嗯......我以前说过很多次，对于记忆力强的巨人来说，记住哪些肌肉需要按什么顺序绷紧就真的很够了。记住整个运动是没有意义的。对于其他不能记住这么多的人来说，记住整个动作，以及肌肉有什么，以什么顺序绷紧，绷到什么程度--把它藏在心里更合理。
对于编译器来说，重载函数只是不同的函数，而没有开关。
访问会有多大的难度？我有一个全局内核，从任何地方都可以看到。在OOP中，我将不得不放弃它。那么我如何在窗口中使用元素呢？当我试图想象它时，我就会昏迷。）
为什么会这样呢？
全局内核和OOP并不相互排斥。
只是窗口中的元素应该被封装在窗口类中，而不是 "躺在明处"。只是为了不让人意外地 "走错地方"。改变一个变量并对其在一个巨大的全局数组中的位置犯错是非常容易的，而查询正确的接口，然后在正确的对象中改变同样的变量并犯错就难多了。
对于编译器来说，重载函数只是不同的函数，而没有开关。
那么如何选择需要的人呢？我们正在谈论虚拟函数 和晚期绑定。哪个重载函数将被调用？这是由this指针决定的，当你调用它时，this指针是隐式传递的。而你认为这种选择是如何作出的？
而我们想要的那个人是如何被选中的呢？我们正在谈论虚拟函数 和晚期绑定。哪个重载函数将被调用？这是由this指针决定的，该指针在调用中隐含地传递。而你认为这种选择是如何做出的？
实际上，彼得并不是在谈论虚拟函数。
但他们也没有任何开关。
一个有虚拟函数的类有一个虚拟函数表。
而这个类的每个对象都包含一个隐性变量--指向虚拟函数表的指针。
如果一个或所有的虚拟函数在子代中被覆盖，就会创建一个新的表，子代实例包含一个指向它的指针。
实际上，彼得并不是在谈论虚拟函数。
但他们也没有任何开关。
一个有虚拟函数的类有一个虚拟函数表。
而这个类的每个对象都包含一个隐性变量--指向虚拟函数表的指针。
如果一个或所有的虚拟函数在子代中被重写，就会创建一个新的表，子代的实例包含一个指向它的指针。
正是如此。我想问的是，这个相同的表格是如何工作的？ 在汇编代码中，它是相同的开关。
而关于 "不谈虚拟函数"--这有点像 "为什么是OOP"...也就是说，它是关于虚拟函数的，而不是关于不同参数的函数的简单相同的名称。
正是如此。所以我的问题是：这个非常表是如何工作的？ 在汇编代码中，它是同样的开关。
不，它只是一个指向函数的指针数组。
汇编代码从对象中获取一个表地址。
它在某一位置获取函数的地址。
并对该地址进行了跳转。
那 "我不是在谈论虚拟函数"呢--这就是我说的 "为什么是OOP"...也就是说，它是关于虚拟函数的，而不仅仅是参数不同的函数的相同名称。
从他的问题来看，他说的是具有相同名称的函数。
他很可能甚至没有意识到虚拟功能。