c – 可能的评估订单或Scott Meyers提供的资源泄漏是错误的吗？

概述我正在阅读Scott Meyers撰写的Effective Modern C 14书中的std :: shared_ptr.这是一个代码,其中作者说,潜在的资源泄漏可能是： int computePriority(); // this function always throw an exception// ...processWidget(std::shared_ptr<Widget>(ne 我正在阅读Scott Meyers撰写的Effective Modern C 14书中的std :: shared_ptr.这是一个代码,其中作者说,潜在的资源泄漏可能是：

int computePriority(); // this function always throw an exception// ...processWidget(std::shared_ptr<Widget>(new Widget),// (S.M): potentital              computePriority());                  // resource                                                   // leak

Scott Meyers说可以在新的Widget和std :: shared_ptr之间调用computePriority()函数< Widget>(expr)表达式会被评估什么会导致新的内存泄漏.不应该有一个序列点,可以保证新的Widget表达式是否被评估,然后std :: shared_ptr< Widget>(expr)将被评估？我想这是因为在我看来这是正确的：序列点在std :: shared_ptr< Widget>(expr)将评估它的所有参数(子表达式)而不进行排序并使共享指针准备就绪,然后做一些事情else(无需排序即可评估其他参数).如果这是不真实的,斯科特迈耶斯是对的(我仍然相信他,显然)
,这种行为会不正确？

是否有规则可以解释为什么这可能？我不擅长序列点,但告诉我他们的人说这应该是有效的.

解决方法 测序并不意味着即时性.
(在我上班之前,我的醒来是有序的,即使我穿好衣服并在中间吃早餐.)

对论证的评价不是相互排序的.

也不是一个参数必须在另一个参数之前完全评估,而不管顺序如何.

也就是说,在shared_ptr构造函数之前对分配进行了排序,但是这些都没有针对另一个参数进行排序,并且不能保证在分配和构造函数调用之间没有任何反应.

总结

以上是内存溢出为你收集整理的c – 可能的评估订单或Scott Meyers提供的资源泄漏是错误的吗？全部内容，希望文章能够帮你解决c – 可能的评估订单或Scott Meyers提供的资源泄漏是错误的吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。