错误、漏洞、问题 - 页 3122 1...311531163117311831193120312131223123312431253126312731283129...3184 新评论 Alexey Viktorov 2021.12.18 16:57 #31211 Vitaly Muzichenko #:如果别人有一个图形对象的程序，你的类型前缀 "l"<其中删除前缀 "l"（名称 "标签"和 "线"被使用时，对象被创建>。 将杀死第三方程序中 所有以"l " 开头的对象。这不是一个好的解决方案。 维塔利，你为什么不进入初学者的主题？这些基础知识或多或少都是程序员长期以来知道的。而只有那些 "明星 "不都知道......。 Vitaly Muzichenko 2021.12.18 17:04 #31212 Alexey Viktorov #:维塔利，你为什么不进入初学者的主题？这些基础知识已经被或多或少的程序员们所熟知了很久。而只有那些 "明星 "不都知道......。 很好! 是的，我可能会去 :) x572intraday 2021.12.18 17:12 #31213 Vitaly Muzichenko #:如果别人有一个程序，在图形上有图形对象，你的类型前缀 "l"<到底是由前缀 "l "删除（名称 "标签"和 "线"被使用，当对象被创建>。 将杀死第三方程序中 所有以"l " 开头的对象。这不是一个好的解决方案。 我也是这么想的。有可能另一个程序员会粘上相同的对象名称或具有相同前缀的名称，所以通过前缀（尤其是短前缀）删除对象比撞上并删除一个名称完全匹配的对象更危险。我们还应该记住，第二个程序将不能用现有的名字创建第二个对象，以前的对象必须保留（在我看来）。在任何情况下，一个决定删除这样一个对象的邻近程序，假设它是它的对象，将删除其他人的同名对象。 到目前为止，我认为唯一的解决办法是：在同一程序中尽可能专门为对象命名，以减少偶然发现一个具有相同名称的外来对象并对其进行不必要的操作的机会。但让我提醒你，前缀加长在技术上并不总是可行的，因为对象名称的长度是有限的。 Vitaly Muzichenko 2021.12.18 17:22 #31214 x572intraday #:我也是这么想的。有可能另一个程序员会做出相同的对象名称或具有相同前缀的名称，所以按前缀删除对象（特别是短的）比撞见并按名称删除完全匹配的对象更危险。我们还应该记住，第二个程序将不能用现有的名字创建第二个对象，以前的对象必须保留（在我看来）。在任何情况下，第二个决定删除这样一个对象的程序，假设它是它的对象，将删除其他人的同名对象。到目前为止，我认为唯一的解决办法是：在同一程序中尽可能专门为对象命名，以减少偶然发现一个具有相同名称的外来对象并对其进行不必要的操作的可能性。但让我提醒你，前缀加长在技术上并不总是可行的，因为对象名称的长度是有限的。 我不需要提醒你，我每天都在与图形对象打交道。 不正确的逻辑是通往......什么的关键？对，失败的关键。这就是你的情况。 x572intraday 2021.12.18 17:50 #31215 Vitaly Muzichenko #:我不需要提醒，我每天都在与图形对象打交道。不正确的逻辑是......什么的关键？对，失败的关键。这就是你的情况。那么什么是失败呢？ 而我提醒你，一般来说，不是你（我们不是私人通信），而是阅读我们的公众，其中可能有业余爱好者。 Vitaly Muzichenko 2021.12.18 17:55 #31216 x572intraday #:那么失败的原因是什么呢？ 我已经描述过了，但选择权在你。 我知道你在写作上付出了很多努力，所以对你来说，这个方案是有价值的，是正确的。但其中有一些缺陷，甚至是关键的缺陷，你觉得难以接受。 就这些了，你自己整理一下吧，我已经描述了我的评估。 x572intraday 2021.12.18 18:14 #31217 Vitaly Muzichenko #:我已经描述过了，但选择权在你。 我已经全面地劝阻了你，只承认你在几个小的非批评性问题上是对的。但是，如果你不被打动和劝阻，我理解--直接从代码的作者那里接受反驳是困难的。 x572intraday 2021.12.18 18:14 #31218 说到寻找免费代码。 试着猜测一下，有多大比例的程序员会搜索程序来帮助他们的交易获利或学习代码。就我个人而言，我认为大多数人都会选择前者，因为在这一领域，将自己视为程序员的人要少得多。 Vitaly Muzichenko 2021.12.18 18:36 #31219 x572intraday #:说到寻找免费代码。试着猜测一下，有多大比例的程序员搜索程序来帮助他们的交易获利或学习代码。我个人认为，优势更倾向于前者，因为搜索的人中，认为自己是这个领域的程序员的要少得多。 关键是这种代码不能在个人机器上使用，但你从未承认这一点。一个程序员当然不会把它放进去，因为他已经看到了代码里面的内容。 他们也开始争论前缀的问题，但我不是来争论的。 好运! x572intraday 2021.12.18 21:50 #31220 Vitaly Muzichenko #:这就是问题所在：你不能在个人机器上使用该代码，但你从未承认它。 我当然没有。因为为了让这些缺陷开始拖累机器，你必须在高负荷的计算中使用它们--例如，在非常、非常胖的循环或非常频繁的重新初始化中。我不建议在这种情况下采用这种代码。但在目前的情况下，一切都飞了起来；关于失败的响亮而矛盾的声明，只不过是一种羞辱。但还是要感谢你。 而且，随着我变得更加开明，我总是愿意改进我的代码。 1...311531163117311831193120312131223123312431253126312731283129...3184 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
如果别人有一个图形对象的程序，你的类型前缀 "l"<其中删除前缀 "l"（名称 "标签"和 "线"被使用时，对象被创建>。
将杀死第三方程序中 所有以"l " 开头的对象。这不是一个好的解决方案。
维塔利，你为什么不进入初学者的主题？这些基础知识或多或少都是程序员长期以来知道的。而只有那些 "明星 "不都知道......。
维塔利，你为什么不进入初学者的主题？这些基础知识已经被或多或少的程序员们所熟知了很久。而只有那些 "明星 "不都知道......。
很好!
是的，我可能会去 :)
如果别人有一个程序，在图形上有图形对象，你的类型前缀 "l"<到底是由前缀 "l "删除（名称 "标签"和 "线"被使用，当对象被创建>。
将杀死第三方程序中 所有以"l " 开头的对象。这不是一个好的解决方案。
我也是这么想的。有可能另一个程序员会粘上相同的对象名称或具有相同前缀的名称，所以通过前缀（尤其是短前缀）删除对象比撞上并删除一个名称完全匹配的对象更危险。我们还应该记住，第二个程序将不能用现有的名字创建第二个对象，以前的对象必须保留（在我看来）。在任何情况下，一个决定删除这样一个对象的邻近程序，假设它是它的对象，将删除其他人的同名对象。
到目前为止，我认为唯一的解决办法是：在同一程序中尽可能专门为对象命名，以减少偶然发现一个具有相同名称的外来对象并对其进行不必要的操作的机会。但让我提醒你，前缀加长在技术上并不总是可行的，因为对象名称的长度是有限的。
我也是这么想的。有可能另一个程序员会做出相同的对象名称或具有相同前缀的名称，所以按前缀删除对象（特别是短的）比撞见并按名称删除完全匹配的对象更危险。我们还应该记住，第二个程序将不能用现有的名字创建第二个对象，以前的对象必须保留（在我看来）。在任何情况下，第二个决定删除这样一个对象的程序，假设它是它的对象，将删除其他人的同名对象。
到目前为止，我认为唯一的解决办法是：在同一程序中尽可能专门为对象命名，以减少偶然发现一个具有相同名称的外来对象并对其进行不必要的操作的可能性。但让我提醒你，前缀加长在技术上并不总是可行的，因为对象名称的长度是有限的。
我不需要提醒你，我每天都在与图形对象打交道。
不正确的逻辑是通往......什么的关键？对，失败的关键。这就是你的情况。
我不需要提醒，我每天都在与图形对象打交道。
不正确的逻辑是......什么的关键？对，失败的关键。这就是你的情况。
那么什么是失败呢？
而我提醒你，一般来说，不是你（我们不是私人通信），而是阅读我们的公众，其中可能有业余爱好者。那么失败的原因是什么呢？
我已经描述过了，但选择权在你。
我知道你在写作上付出了很多努力，所以对你来说，这个方案是有价值的，是正确的。但其中有一些缺陷，甚至是关键的缺陷，你觉得难以接受。
就这些了，你自己整理一下吧，我已经描述了我的评估。
我已经描述过了，但选择权在你。
我已经全面地劝阻了你，只承认你在几个小的非批评性问题上是对的。但是，如果你不被打动和劝阻，我理解--直接从代码的作者那里接受反驳是困难的。
说到寻找免费代码。
试着猜测一下，有多大比例的程序员会搜索程序来帮助他们的交易获利或学习代码。就我个人而言，我认为大多数人都会选择前者，因为在这一领域，将自己视为程序员的人要少得多。
说到寻找免费代码。
试着猜测一下，有多大比例的程序员搜索程序来帮助他们的交易获利或学习代码。我个人认为，优势更倾向于前者，因为搜索的人中，认为自己是这个领域的程序员的要少得多。
关键是这种代码不能在个人机器上使用，但你从未承认这一点。一个程序员当然不会把它放进去，因为他已经看到了代码里面的内容。
他们也开始争论前缀的问题，但我不是来争论的。
好运!
这就是问题所在：你不能在个人机器上使用该代码，但你从未承认它。
我当然没有。因为为了让这些缺陷开始拖累机器，你必须在高负荷的计算中使用它们--例如，在非常、非常胖的循环或非常频繁的重新初始化中。我不建议在这种情况下采用这种代码。但在目前的情况下，一切都飞了起来；关于失败的响亮而矛盾的声明，只不过是一种羞辱。但还是要感谢你。
而且，随着我变得更加开明，我总是愿意改进我的代码。