对OOP的帮助 - 页 4 123456789 新评论 Dmitry Fedoseev 2021.09.27 10:57 #31 Vasiliy Sokolov #:官方说，是的。非官方的，许多事情表明它确实存在。 在MQL中没有指针。相反，它们被一些看起来很像它们的东西所取代。 在MQL中没有直接的内存分配，例如在C中。 MQL中的程序是由某个虚拟机执行的。雷纳特简短地写了一下，而且一次也没有。 可以定义将被自动释放的类实例。因此，有一些机制可以监控这些实例，并在必要时释放它们。如果不是垃圾收集者，那是什么？ 任何通过指针初始化并且没有正确释放的实例在退出时将被标记为泄漏的对象。它们的数量和丢失的内存的总大小将被打印出来。一个内存泄漏的程序甚至不会在市场中得到验证。因此，所有的对象，甚至是手动分配的对象，都被计算在内，并为系统所知。这是垃圾收集者解决的经典任务之一。 有一个充分和全面的迹象表明，在emcool中没有垃圾收集器--删除是新的之后强制的。 Georgiy Merts 2021.09.29 06:08 #32 Dmitry Fedoseev #:有一个充分和足够的迹象表明，在emcool中没有垃圾收集器--删除是新的之后强制的。 在我的记忆中，其中一个开发商承认有一个垃圾收集者。但对用户来说，它 "有点不存在"。 好吧，关于新-删除对-我完全支持。在一般情况下，请求资源的对象必须对其负责。也有例外，比如 "对象工厂"--但那里特别假定，创建对象的责任在于从工厂请求这些对象的人。 我不喜欢语言中存在新的东西，但不需要删除的情况，因为 "系统会删除不必要的东西"。这不仅有可能降低性能（当不必要的对象还没有被删除时），而且还能让编码者放松，让他不关心自己行为的后果。 Vasiliy Sokolov 2021.09.29 08:25 #33 Georgiy Merts #:我真的不喜欢语言中的情况，即新的东西在那里，但删除是不需要的，说 "系统会删除不必要的"。这不仅有可能降低性能（当不必要的对象还没有被删除时），而且还能让编码者放松，让他不关心自己行为的后果。 另一方面，生产力也普遍得到了提高。手动删除需要在主线上花费大量时间。+ 删除是逐个元素进行的。例如，比较本线程中的两个版本的脚本。速度上的差异是几倍。内存效率也上升了。因为垃圾收集器移动的物体是相互压实的。如果你手动管理，就会产生空闲的内存孔，不那么容易再使用。另外，垃圾收集器在不同的线程中工作。基本的时间没有被浪费。总而言之，一加。 Dmitry Fedoseev 2021.09.29 08:52 #34 Vasiliy Sokolov #:相反，生产力则普遍提高。人工清除需要在主流中花费相当多的时间。+ 删除是逐个元素进行的。例如，比较本线程中的两个版本的脚本。速度上的差异是几倍。内存效率也上升了。因为垃圾收集器移动的物体是相互压实的。如果你手动管理，就会产生空闲的内存孔，不那么容易再使用。另外，垃圾收集器在不同的线程中工作。基本的时间没有被浪费。总而言之，这只是一个补充。 瓦西里，我很抱歉，但你根本不明白你想谈的是什么。完全没有，也不可能。 至少读一下维基百科，什么是垃圾收集者。它的主要特点是，它删除了与之失去联系的物体。 只是在这种情况下，它将被称为垃圾收集者。这两个剧本是来自不同的故事。上帝的礼物不能与鸡蛋混为一谈。 而且为什么垃圾收集器会突然提高生产力？它是有用的代码和硬件之间的又一个填充物，而且不是一个薄弱的填充物。 Dmitry Fedoseev 2021.09.29 09:16 #35 Georgiy Merts #:我记得，其中一个开发者承认，垃圾收集者确实存在。但对用户来说，它 "有点消失了"。/// 这可能是 "垃圾收集器"，它在工作结束时给出了一条关于内存泄漏的信息。 也许它甚至会删除被遗弃的物品。但是，即使删除了它们，也有一个很大的 不同的是--它只在工作结束时删除它们。如果在几千次的循环中，有新的对象被创造出来呢？ 新的对象？程序将无法运行，没有足够的内存。 一个真正的汇编者会在程序操作过程中删除丢失的对象，而非 只有在计划结束时才会出现。这就是为什么允许采用特殊的编程风格。 我们可以在任何条件下和任何数量的物体相乘。 Georgiy Merts 2021.09.29 09:27 #36 Vasiliy Sokolov #:相反，生产力则普遍提高。手动删除需要大量的时间，在主流。+ 删除是逐个元素进行的。例如，比较本线程中的两个版本的脚本。速度上的差异是几倍。内存效率也上升了。因为垃圾收集器移动的物体是相互压实的。如果你手动管理，就会产生空闲的内存孔，不那么容易再使用。另外，垃圾收集器在不同的线程中工作。基本的时间没有被浪费。总而言之，一加。 嗯...而在一个垃圾收集器中，删除是非元素性的？更不用说另一个线程，当没有空闲的核心时，由同一个核心来执行，并使主线程变慢。 在我看来，在一般情况下，只要仔细考虑，由用户清除垃圾总是比由垃圾收集器清除更有效。然而，如果你不关心，垃圾收集者肯定会赢。 这就是为什么我不喜欢垃圾收集器，因为它鼓励这种对资源的冷漠对待。 Georgiy Merts 2021.09.29 09:32 #37 Dmitry Fedoseev #:这一定是 "汇编器"，当工作完成时，会给出关于内存泄漏的信息。 它甚至可能会删除残留的对象。但即使它删除了它们，也有一个很大的 不同的是--它只在工作结束时删除它们。如果在几千次的循环中，有新的对象被创造出来呢？ 新的对象？程序将无法运行，没有足够的内存。一个真正的汇编者会在程序操作过程中删除丢失的对象，而非只有在计划结束时才会出现。这就是为什么允许采用特殊的编程风格。我们可以在任何条件下和任何数量的物体相乘。 这就对了。这就是为什么我不喜欢用汇编程序工作--用户不注意，他/她创建了多少个对象，在哪里。 基本上，它甚至在某种程度上简化了开发工作--你不必记得删除繁忙的那个。创建者找到对象不再被引用的时刻，并将其删除。但这种立场让我感到厌恶。正是由于这种立场，我们的程序运行速度越来越慢，对于类似复杂程度的任务，需要越来越多的强大硬件资源。 Vasiliy Sokolov 2021.09.29 13:32 #38 Dmitry Fedoseev #:瓦西里，我很抱歉，但你根本不了解你想争论的东西。完全没有，也没有任何方式。Dmitry，不好意思，除了mukl，你还会其他的编程语言吗？不，你不知道。而且你仍然没有学会如何使用对象和指针，从你发表的那几段代码甚至文章中可以看出。这就是为什么我甚至不能认真地回复这个无能和坦率的愚蠢评论。最后读读维基百科，了解一下什么是垃圾收集器，以及它是如何组织的，最后至少读一遍你想参考的内容。到目前为止，这一切看起来就像狗对大篷车的吠叫：毫无意义，毫不留情。 Vasiliy Sokolov 2021.09.29 13:41 #39 Georgiy Merts #:嗯...而在垃圾收集器中，删除是非元素性的吗？更不用说另一个线程，当没有空闲的核心时--是由同一个核心来完成的，并且拖慢了主线程。在我看来，一般来说，只要仔细考虑，由用户清除垃圾总是比由垃圾收集器清除更有效率。然而，如果你不关心，垃圾收集者肯定会赢。这就是为什么我不喜欢垃圾收集器，它鼓励这种对资源的冷漠对待。 与其对垃圾收集器的工作方式进行假设，不如将自动删除对象的速度与手动删除进行比较。所有的幻想都会马上消失。 fxsaber 2021.09.29 13:42 #40 Vasiliy Sokolov #:比较自动去除物体和手动去除物体的速度。 答案最好是马上就有。并不总是有时间做实验。 123456789 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
官方说，是的。非官方的，许多事情表明它确实存在。
有一个充分和全面的迹象表明，在emcool中没有垃圾收集器--删除是新的之后强制的。
有一个充分和足够的迹象表明，在emcool中没有垃圾收集器--删除是新的之后强制的。
在我的记忆中，其中一个开发商承认有一个垃圾收集者。但对用户来说，它 "有点不存在"。
好吧，关于新-删除对-我完全支持。在一般情况下，请求资源的对象必须对其负责。也有例外，比如 "对象工厂"--但那里特别假定，创建对象的责任在于从工厂请求这些对象的人。
我不喜欢语言中存在新的东西，但不需要删除的情况，因为 "系统会删除不必要的东西"。这不仅有可能降低性能（当不必要的对象还没有被删除时），而且还能让编码者放松，让他不关心自己行为的后果。
我真的不喜欢语言中的情况，即新的东西在那里，但删除是不需要的，说 "系统会删除不必要的"。这不仅有可能降低性能（当不必要的对象还没有被删除时），而且还能让编码者放松，让他不关心自己行为的后果。
另一方面，生产力也普遍得到了提高。手动删除需要在主线上花费大量时间。+ 删除是逐个元素进行的。例如，比较本线程中的两个版本的脚本。速度上的差异是几倍。内存效率也上升了。因为垃圾收集器移动的物体是相互压实的。如果你手动管理，就会产生空闲的内存孔，不那么容易再使用。另外，垃圾收集器在不同的线程中工作。基本的时间没有被浪费。总而言之，一加。
相反，生产力则普遍提高。人工清除需要在主流中花费相当多的时间。+ 删除是逐个元素进行的。例如，比较本线程中的两个版本的脚本。速度上的差异是几倍。内存效率也上升了。因为垃圾收集器移动的物体是相互压实的。如果你手动管理，就会产生空闲的内存孔，不那么容易再使用。另外，垃圾收集器在不同的线程中工作。基本的时间没有被浪费。总而言之，这只是一个补充。
瓦西里，我很抱歉，但你根本不明白你想谈的是什么。完全没有，也不可能。
至少读一下维基百科，什么是垃圾收集者。它的主要特点是，它删除了与之失去联系的物体。
只是在这种情况下，它将被称为垃圾收集者。这两个剧本是来自不同的故事。上帝的礼物不能与鸡蛋混为一谈。
而且为什么垃圾收集器会突然提高生产力？它是有用的代码和硬件之间的又一个填充物，而且不是一个薄弱的填充物。
我记得，其中一个开发者承认，垃圾收集者确实存在。但对用户来说，它 "有点消失了"。
///
这可能是 "垃圾收集器"，它在工作结束时给出了一条关于内存泄漏的信息。
也许它甚至会删除被遗弃的物品。但是，即使删除了它们，也有一个很大的
不同的是--它只在工作结束时删除它们。如果在几千次的循环中，有新的对象被创造出来呢？
新的对象？程序将无法运行，没有足够的内存。
一个真正的汇编者会在程序操作过程中删除丢失的对象，而非
只有在计划结束时才会出现。这就是为什么允许采用特殊的编程风格。
我们可以在任何条件下和任何数量的物体相乘。
相反，生产力则普遍提高。手动删除需要大量的时间，在主流。+ 删除是逐个元素进行的。例如，比较本线程中的两个版本的脚本。速度上的差异是几倍。内存效率也上升了。因为垃圾收集器移动的物体是相互压实的。如果你手动管理，就会产生空闲的内存孔，不那么容易再使用。另外，垃圾收集器在不同的线程中工作。基本的时间没有被浪费。总而言之，一加。
嗯...而在一个垃圾收集器中，删除是非元素性的？更不用说另一个线程，当没有空闲的核心时，由同一个核心来执行，并使主线程变慢。
在我看来，在一般情况下，只要仔细考虑，由用户清除垃圾总是比由垃圾收集器清除更有效。然而，如果你不关心，垃圾收集者肯定会赢。
这就是为什么我不喜欢垃圾收集器，因为它鼓励这种对资源的冷漠对待。
这一定是 "汇编器"，当工作完成时，会给出关于内存泄漏的信息。
它甚至可能会删除残留的对象。但即使它删除了它们，也有一个很大的
不同的是--它只在工作结束时删除它们。如果在几千次的循环中，有新的对象被创造出来呢？
新的对象？程序将无法运行，没有足够的内存。
一个真正的汇编者会在程序操作过程中删除丢失的对象，而非
只有在计划结束时才会出现。这就是为什么允许采用特殊的编程风格。
我们可以在任何条件下和任何数量的物体相乘。
这就对了。这就是为什么我不喜欢用汇编程序工作--用户不注意，他/她创建了多少个对象，在哪里。
基本上，它甚至在某种程度上简化了开发工作--你不必记得删除繁忙的那个。创建者找到对象不再被引用的时刻，并将其删除。但这种立场让我感到厌恶。正是由于这种立场，我们的程序运行速度越来越慢，对于类似复杂程度的任务，需要越来越多的强大硬件资源。
瓦西里，我很抱歉，但你根本不了解你想争论的东西。完全没有，也没有任何方式。
嗯...而在垃圾收集器中，删除是非元素性的吗？更不用说另一个线程，当没有空闲的核心时--是由同一个核心来完成的，并且拖慢了主线程。
在我看来，一般来说，只要仔细考虑，由用户清除垃圾总是比由垃圾收集器清除更有效率。然而，如果你不关心，垃圾收集者肯定会赢。
这就是为什么我不喜欢垃圾收集器，它鼓励这种对资源的冷漠对待。
与其对垃圾收集器的工作方式进行假设，不如将自动删除对象的速度与手动删除进行比较。所有的幻想都会马上消失。
比较自动去除物体和手动去除物体的速度。
答案最好是马上就有。并不总是有时间做实验。