模板参数=void*的编译器错误 - 页 7 1234567891011121314...20 新评论 fxsaber 2018.12.20 07:48 #61 Alexey Navoykov:我本来是这样做的。 我觉得这种风格让人不舒服。这就是说,它归结为 "毡尖笔"。 Alexey Navoykov 2018.12.20 07:52 #62 fxsaber:所以你也想要警告?这是什么双重标准:在这两个地方,行为都是毫不含糊的,但在括号里你反对警告,而在这里你却赞成?你需要一个警告,这样你就不会犯难以发现的错误。因此,难度是一个主观的评估。因此,有了括号,你就不会犯错,而在这里你可以。而对我来说,反之亦然。 那么,我们中的哪一位应该调整发布警告的规则?你似乎没有理解这一点。 动态铸造必须始终是一个显式操作。在任何正常的语言中,无论是C++、C#、Java还是其他的OOP语言,这样的代码都不会被编译。这就是可靠的OOP的基础。但不知为何在这里被遗忘了。 我认为支架的比较在这里一点也不合适。 fxsaber 2018.12.20 08:05 #63 Alexey Navoykov:可靠的OOP的基本原理的基础。在不含糊的基础上。 pavlick_ 2018.12.20 08:30 #64 Ilya Malev:我不明白参考代码的意义(尽管我也不使用标准库)。如果将一个对象放入数组中涉及到创建它的副本,那么赋值方法或复制构造函数必须在这个类中明确声明和描述,否则无论如何都没有包装器的帮助。如果你只需要把一个对象的引用放到数组中,你根本不需要任何包装器(为什么?) 你需要这样一个阵列做什么?因为它几乎类似于一个加法向量,它应该像向量<int>、向量<class_name>、向量<class_name*>那样工作。如果你能通过µl的方式实现它而不进行包装,对你来说是好事(我认为你不能)。你没有能力贯穿一个数组并调用析构器(_data[i].~Destr()),没有部分专业化,也没有SFINAE的技巧。这种包装使数组适合于指向堆中的对象的指针,而不会破坏使用vector<int>的可能性,比如说。 vector<unique_ptr<my_class>> v1;vector<my_class> v2; vector<int> v3; ZS: 怎么说呢,vector<class_name*>不会像预期的那样工作,即使在pluses(vector生命结束时调用析构器)也需要包装。 Ilya Malev 2018.12.20 08:51 #65 pavlick_:ZS: 怎么说呢,vector<class_name*>不会像预期的那样工作,即使在pluses(vector寿命结束时调用析构器),它也需要包装。这能行吗?) template<typename T> void del(T par){printf("%s не удаляем",typename(T));} template<typename T> void del(T *par){printf("%s удаляем",typename(T));delete par;} class A{public:void~A(void){printf("удаляем %i",&this);}}; void OnStart() { int var1; A *var2=new A; del(var1); del(var2); } P.S. 以此类推,一个函数可以返回任何东西而不是void,而且不需要SFINAE。 pavlick_ 2018.12.20 09:01 #66 是的,这很好。但我们仍然需要一个封装器:我们需要一个通用数组,所以有时它有需要删除的指针,有时没有(好吧,只是一组指针--在另一个数组中找到的结果)。 Alexey Navoykov 2018.12.20 09:07 #67 pavlick_:从好的方面看,删除void*是UB。顺便说一下,我以前都没有想过这个问题,谢谢你的提示。 事实证明,delete在这种情况下与free()类似。 它应该是被禁止的,因为delete被定位为对象,它只是绕过规则释放了内存。 虽然这里也会调用析构器,但在将代码移植到C++时,可能会遇到麻烦。 Ilya Malev 2018.12.20 09:12 #68 pavlick_: 是的,这就可以了。但我们仍然需要包装:毕竟我们需要通用数组,所以有时它有需要做删除的指针,有时没有(好吧,只是一堆指针--在另一个数组中寻找东西的结果)。好吧,没有人禁止在创建数组时传递额外的选项--在删除元素时是否删除,并使其默认为开或关(根据自己的喜好)。毕竟,你永远无法猜测你是否要删除项目))。 P.S. 顺便说一下,在将指针放入数组之前对其进行包装并不能解决在删除数组时是否需要删除其基础对象的问题)) A100 2018.12.20 09:55 #69 fxsaber:额外的括号已经完全消除了语言优先权的影响。一切都变得完全不含糊。这使得它100%可靠,在下一次构建后不会有任何损坏。考虑到这一点,我将进行总结。 A100开发商fxsaber支架只有在必须的地方才会有。也许甚至在MQL4之前不同的地方也是如此到处都需要他们不必要的警告不需要只有在MQL4之前不同的地方,才有可能出现。到处都需要优先事项是必需的需要原则上不需要(因为括号代替了它们) 如果我说得不对--请纠正我--我已经把我的概念说得很短,而且在需要警告括号的地方不含糊。 pavlick_ 2018.12.20 09:58 #70 Ilya Malev:好吧,没有人禁止在创建数组时传递额外的选项--在删除元素时是否删除,并使其默认为开或关(根据自己的喜好)。因为它很难猜测,你是否应该删除项目))。一般来说,是的,你可以这样做。 P.S.顺便说一下,仅仅因为你在将指针放入数组之前将其包裹起来,在删除数组时是否需要删除其基对象的问题就不会变得更清楚)) 如果你不包裹它,你就不会删除它,如果你包裹它,你就会删除它,这很清楚。 ZS: 但如果我这样做,我会尽可能做得与标准加库相似(名称、行为等),所以对我来说没有选择。既然一切都已经写好了,为什么还要再创造一个规格呢? 1234567891011121314...20 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
我本来是这样做的。
我觉得这种风格让人不舒服。这就是说,它归结为 "毡尖笔"。
所以你也想要警告?这是什么双重标准:在这两个地方,行为都是毫不含糊的,但在括号里你反对警告,而在这里你却赞成?
你需要一个警告,这样你就不会犯难以发现的错误。因此,难度是一个主观的评估。因此,有了括号,你就不会犯错,而在这里你可以。而对我来说,反之亦然。
那么,我们中的哪一位应该调整发布警告的规则?
你似乎没有理解这一点。 动态铸造必须始终是一个显式操作。在任何正常的语言中,无论是C++、C#、Java还是其他的OOP语言,这样的代码都不会被编译。这就是可靠的OOP的基础。但不知为何在这里被遗忘了。 我认为支架的比较在这里一点也不合适。
可靠的OOP的基本原理的基础。
在不含糊的基础上。
我不明白参考代码的意义(尽管我也不使用标准库)。如果将一个对象放入数组中涉及到创建它的副本,那么赋值方法或复制构造函数必须在这个类中明确声明和描述,否则无论如何都没有包装器的帮助。如果你只需要把一个对象的引用放到数组中,你根本不需要任何包装器(为什么?)
你需要这样一个阵列做什么?因为它几乎类似于一个加法向量,它应该像向量<int>、向量<class_name>、向量<class_name*>那样工作。如果你能通过µl的方式实现它而不进行包装,对你来说是好事(我认为你不能)。你没有能力贯穿一个数组并调用析构器(_data[i].~Destr()),没有部分专业化,也没有SFINAE的技巧。这种包装使数组适合于指向堆中的对象的指针,而不会破坏使用vector<int>的可能性,比如说。
vector<unique_ptr<my_class>> v1;
vector<my_class> v2;
vector<int> v3;
ZS: 怎么说呢,vector<class_name*>不会像预期的那样工作,即使在pluses(vector寿命结束时调用析构器),它也需要包装。
这能行吗?)
P.S. 以此类推,一个函数可以返回任何东西而不是void,而且不需要SFINAE。
从好的方面看,删除void*是UB。
顺便说一下,我以前都没有想过这个问题,谢谢你的提示。 事实证明,delete在这种情况下与free()类似。 它应该是被禁止的,因为delete被定位为对象,它只是绕过规则释放了内存。
虽然这里也会调用析构器,但在将代码移植到C++时,可能会遇到麻烦。
是的,这就可以了。但我们仍然需要包装:毕竟我们需要通用数组,所以有时它有需要做删除的指针,有时没有(好吧,只是一堆指针--在另一个数组中寻找东西的结果)。
好吧,没有人禁止在创建数组时传递额外的选项--在删除元素时是否删除,并使其默认为开或关(根据自己的喜好)。毕竟,你永远无法猜测你是否要删除项目))。
P.S. 顺便说一下,在将指针放入数组之前对其进行包装并不能解决在删除数组时是否需要删除其基础对象的问题))额外的括号已经完全消除了语言优先权的影响。一切都变得完全不含糊。这使得它100%可靠,在下一次构建后不会有任何损坏。
考虑到这一点,我将进行总结。
如果我说得不对--请纠正我--我已经把我的概念说得很短,而且在需要警告括号的地方不含糊。
好吧,没有人禁止在创建数组时传递额外的选项--在删除元素时是否删除,并使其默认为开或关(根据自己的喜好)。因为它很难猜测,你是否应该删除项目))。
一般来说,是的,你可以这样做。
如果你不包裹它,你就不会删除它,如果你包裹它,你就会删除它,这很清楚。
ZS: 但如果我这样做,我会尽可能做得与标准加库相似(名称、行为等),所以对我来说没有选择。既然一切都已经写好了,为什么还要再创造一个规格呢?